AW: [riena-dev] 3.4 Tree Databinding

["Drossel, Carsten" <Carsten.Drossel@xxxxxxxxxxxx>]

Hi Elias,

with the changes you propose it looks like we can get rid of the ITreeModel and at least have a much simpler version of the ITreeNode. This would definitely be a major improvement.

What I'm a little worried about is the TreeTableRidget. The information that is now in the ITreeTableModel (number of columns, column labels, which column is the tree column) will have to be moved. Maybe there could be a TreeTableColumnModel and a special bind method for the TreeTableRidget that allows to specify it as another parameter.

In the Swing application a TreeTable is implemented by using a JTree as a renderer for one column of a JTable. Expanding and collapsing the tree changes the number of rows of the table. Do you think this can be implemented in SWT?

Greetings,
Carsten


> -----Ursprüngliche Nachricht-----
> Von: riena-dev-bounces@xxxxxxxxxxx [mailto:riena-dev-
> bounces@xxxxxxxxxxx] Im Auftrag von Volanakis, Elias
> Gesendet: Dienstag, 8. Juli 2008 03:05
> An: Riena Developers list
> Betreff: [riena-dev] 3.4 Tree Databinding
> 
> Hi Christian & Carsten,
> 
> I spend some time today to look at the Tree Databinding in 3.4. The
> attached .zip contains an example project that should work in Eclipse
> 3.4. Make sure to disable the Riena target first.
> 
> Requirements:
> 
> In general I like the 3.4 approach for Trees because it is very simple.
> The bean in the tree has to satisfy these requirements:
> - a pair of get/setXXXXX methods that provide access to a Set/List of
> children
> - a pair of get/setXXXXX methods that provide access to a Value
> 
> Drawbacks:
> 
> - all Beans have to be of the same class (in the example: StringBean)
> - beans have to provide access to the Set/List of their children
> - label provider does not support images (but we can easily add support
> for fixed style "folder" images)
> 
> See my modified StringBean class and Snippet020StringBean for details.
> 
> 
> Recommendation:
> 
> Assuming we can break API:
> 
> (a) if we are ok with imposing the above requirements on the bean we
> could have a method like:
> 
> AnyBean rootElement;
> treeRidget.bind(rootElement, AnyBean.class, "children", "value");
> // "children" -> beanInstance#get/setChildren() // "value" ->
> beanInstance#get/setValue()
> 
> and get rid of the ITreeNode / ITreeModel and subclasses.
> 
> (b) Additionally, a more flexible approach that requires wrapping is
> using a very light-weight ITreeNode that satisfies the requirements
> above. Based on the original ITreeNode I've created a minimal version
> that has only get/setChildren; get/setValue; getParent methods. All
> other functionality has moved away from the interface into a utility
> class TreeNodeUtils. This makes the implementation of ITreeNode very
> easy, while providing the same amount of functionality (comparable to
> the original ITreeNode / ITreeModel). The only thing missing is support
> for the ITreeNodeModelListener, which is not needed anymore.
> 
> See ITreeNode / TreeNode / Snippet020TreeNode for details.
> 
> The benefit of this approach is that we can still use the Eclipse
> Databinding; but can wrap more than one bean type at a time. I.e. from
> Eclipse POV we bind to the type TreeNode; however the TreeNode can wrap
> any bean. This style also imposes less requirements on the Bean. The
> drawback is the wrapping.
> 
> The usage would be the same, so it can be combined with approach (a):
> 
> TreeNode rootElement;
> treeRidget.bind(rootElement, TreeNode.class, "children", "value");
> 
> Let me know what you think of this.
> 
> @Carsten: if you would like to discuss, feel free to join our call on
> Wednesday or contact me via skype.
> 
> Kind regards,
> Elias.
> 
> ---
> Elias Volanakis
> Technical Lead
> Innoopract, Inc.
> 351 NW 12th Avenue
> Portland, Oregon 97209
> Tel: +1-503-552-1457
> Fax: +1-503-715-4915
> Mobile: +1-503-929-5537
> evolanakis@xxxxxxxxxxxxxx
> http://rapblog.innoopract.com