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