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 Elias,

1. Cool, that looks pretty coherent. But we don't need the "value" parameter because the values of the cells in the tree column are also specified by 'String[] columnPropertyNames', right? Otherwise we would have two values for the tree column.

2. I don't think I have ever seen a TreeTable with a tree column other than the leftmost. So at least for the start we could leave the get/setTreeColumnIndex methods out of it an just assume column 0.

3. In the old swing application you can use a ridget as a value of a table cell. A special renderer dynamically creates a matching widget. This is used to show an image with a text (LabelRidget), a checkbox etc. On the other hand a checkbox should also be shown if the value is a boolean. I think for the start checkboxes and images should be enough. Maybe we don't need inner ridgets for that. Can you think of another way to show images in table cells with our table ridget approach?

Greetings,
Carsten


> -----Ursprüngliche Nachricht-----
> Von: riena-dev-bounces@xxxxxxxxxxx [mailto:riena-dev-
> bounces@xxxxxxxxxxx] Im Auftrag von Volanakis, Elias
> Gesendet: Mittwoch, 9. Juli 2008 00:34
> An: Riena Developers list
> Betreff: 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/Ecl
> ipse%20JFace%20Snippets/org/eclipse/jface/snippets/viewers/Snippet026Tr
> eeViewerTabEditing.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
> _______________________________________________
> riena-dev mailing list
> riena-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/riena-dev


Back to the top