pivot-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roger L. Whitcomb" <Roger.Whitc...@ingres.com>
Subject RE: Getting a TreeView node from mouse click
Date Fri, 03 Sep 2010 15:41:42 GMT
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??




Roger Whitcomb | Architect, Engineering | Roger.Whitcomb@ingres.com|
Ingres | 500 Arguello Street | Suite 200 | Redwood City | CA | 94063 |
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:gkbrown@mac.com] 
Sent: Friday, September 03, 2010 7:42 AM
To: user@pivot.apache.org
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.




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:




	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


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.










View raw message