Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
AW: [riena-dev] 3.4 Tree Databinding 
Hi Carsten,

thanks for your feedback. 

I think your concerns regarding the ITreeTableModel could be addressed in the following way, while still allowing to eliminate the I***Model stuff:


1. I suggest a bind method on the ITreeTableRidget that is similar to the proposed bind method for the ITreeRidget but includes column information (as in the bind method of the ITableRidget):

treeTableRidget.bind(
  rootElement, 
  AnyBean.class, 
  "children", 
  "value",
  String[] columnPropertyNames,
  String[] columnHeaders);


2. The methods in ITreeTableModel are generally useful and should be moved to the ridgets:

ITableRidget:
+ int getColumnCount()
+ String getColumnName(); // rename to getColumnHeader()

ITreeTableRidget:
+ int getTreeColumnIndex()
+ void setTreeColumnIndex(int) // new method ?
+ Object getValueAt(ITreeTableNode node, int column); // uses column info from ridget

AFAIK in SWT the tree is always on the left, and the leftmost column is used for the tree's labels. To see what I mean start the snippet below and see what happens when you re-order the columns via drag&drop:

http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.jface.snippets/Eclipse%20JFace%20Snippets/org/eclipse/jface/snippets/viewers/Snippet026TreeViewerTabEditing.java?revision=HEAD

>From my POV this is confusing. I would probably disable re-ordering - at least for the first column. In that case getTreeColumnIndex would return 0 always and setTreeColumnIndex throw an UnsupportedOperationException.


3. The area that is still very unclear to me, is supporting having arbitrary SWT controls in the columns while using viewers and the databinding. Is that something that Riena wants to have in the future? If yes, it could be worth investigating this, because it may affect the Tree/TableRidget implementations. However maybe we will have an different type of Tree/TableRidget for that.

Carsten, as far as I know in Swing this is handled by returning a Ridget as the column value and the our swing renderer somehow is able to make use that. Is that correct? See the checkbox in Column-2 of the "Grouped Table" in swing for an example.

Kind regards,
Elias.


-----Ursprüngliche Nachricht-----
Von: riena-dev-bounces@xxxxxxxxxxx [mailto:riena-dev-bounces@xxxxxxxxxxx] Im Auftrag von Drossel, Carsten
Gesendet: Tuesday, July 08, 2008 02:24
An: Riena Developers list
Betreff: AW: [riena-dev] 3.4 Tree Databinding

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

_______________________________________________
riena-dev mailing list
riena-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/riena-dev

Back to the top