I can see the value in adding a "userData" property of type Object (whose initial value could simply be null). This has come up a couple of times now so it is probably worth doing.
However, my point was that the default TreeNode and TreeBranch classes may not be used all that often in practice. Doing so may not produce the most efficient application, unless the server actually returns a data structure consisting of these classes. Otherwise, the data returned by the server will have to be transformed into a data structure containing TreeNodes and TreeBranches. This will require traversing the entire structure, which isn't as efficient as simply using the data returned by the server as the model and using a custom renderer. G On Sep 3, 2010, at 9:17 AM, Chris Bartlett wrote: > >> 2. I don’t see any place for “userData” in the TreeNode object, so if >> I want to add stuff (for instance, that is language-independent so I can do >> string compares on it in any language), do I have to subclass TreeNode >> and/or TreeBranch to create a compatible object to populate the TreeView >> data model with? > > The reason there is no "userData" property on TreeNode is because TreeNode > and TreeBranch are simply the default implementations for these classes. Any > class that implements List can be a branch, and any Object can be a leaf - > you just need to define an appropriate renderer. The default > TreeViewNodeRenderer is capable of rendering TreeNode and TreeBranch, but it > is fairly easy to write your own - you can see an example of a custom > renderer in the XML Viewer demo: > > > http://svn.apache.org/repos/asf/pivot/trunk/demos/src/org/apache/pivot/demos/xml/ > > This application uses a custom renderer to present instance of > org.apache.pivot.xml.Element and org.apache.pivot.xml.TextNode as branches > and leaves, respectively. > > Depending on how you get the data for your tree view, you may find that a > custom renderer is more efficient. For example, if you return a tree > structure as XML from the server, you could do something similar to what is > done in XML Viewer. You can simply use the deserialized XML (obtained from > XMLSerializer) as your tree model data. This saves the step of converting > your data into TreeNodes and TreeBranches for presentation in the TreeView. > > I certainly see the value of giving the default TreeNode some sort of place > holder for user data, but think that a simple Object might suffice. > > If the user needs the specific functionality of a Map they can place one in > there, likewise with any other type of Object. Defaulting to just an Object > would remove the overhead of creating a new and potentially unrequired > UserData Map, but the lazy initialization could be used to keep the nodes as > lightweight as possible if it is a genuine concern. Overall though, I don't > mind much either way ;) > > I believe that adding something like this would be beneficial as it would > allow users to focus on just writing a new TreeView.NodeRenderer (or > extending TreeViewNodeRenderer), and I don't see a downside to such a simple > change. > > Regards, > > Chris > > > >
