Understood. I should have just written '+1 for userData property' :) On 3 September 2010 21:42, Greg Brown <[email protected]> wrote:
> 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 > > > > > >
