My tree is being constructed with some static elements (loaded with a simple WTKX / BXML file) combined with dynamic elements I get from SQL queries when the appropriate tree item is expanded and then some more static elements attached to those dynamic ones. So, there is no one "natural" object that represents all the tree elements, and the icon+string rendering is fine. It's just that in order to decipher what the node type is (for determining the right-click context menu contents, among other things) it is easier to have a different object (in my case I'm using an enum) to look at (rather than having to compare the possibly localized display names in the tree). I have implemented (locally) this patch (including the extra "String" override for the userData field and it seems to be working fine. Would you consider making this change part of the project??
Thanks. Roger Whitcomb | Architect, Engineering | [email protected]| Ingres | 500 Arguello Street | Suite 200 | Redwood City | CA | 94063 | USA <http://www.google.com/maps?f=q&hl=en&geocode=&q=500+Arguello+Street+%7C +Suite+200+%7C+Redwood+City+%7C+CA+%7C+94063+%7C+USA+&sll=37.0625,-95.67 7068&sspn=50.557552,73.037109&ie=UTF8&t=h&z=16&iwloc=addr> | +1 650-587-5596 | fax: +1 650-587-5550 From: Greg Brown [mailto:[email protected]] Sent: Friday, September 03, 2010 7:42 AM To: [email protected] Subject: Re: Getting a TreeView node from mouse click 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/d emos/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
userdata.diff
Description: userdata.diff
