Sean,
I'm sorry if I was not specific enough in my first attempt so let's try again:
o) TreeNode instead of TreeModel
My argument here is that TreeModel in the way it is used by the current tree component and in the way it is used by the Swing JTree is more generic and lightweight than your approach using TreeNode. If you have a look at the JTree sources you'll see that despite there are constructors taking a TreeNode as their argument, internally JTree is operating on a TreeModel. The TreeNode interface and DefaultTreeModel are just helpers to make it easier for the user to create a TreeModel instance. You will not find any reference to TreeNode in the JTree sources besides the constructors which just take the node to build a DefaultTreeModel instance used as the model.
And according the 3rd party library: I have a java library based on a library of C functions which provides access to some kind of hierarchical data I have to present in a tree. At the moment I have an implementation of TreeModel (as used by the current tree component) which uses named 3rd party lib to provide the tree with the data to display. The implementation of TreeModel is straightforward as it's just an adapter to the external API and uses/returns the objects it gets from there. So far, so simple. Now consider your programming model where I have to provide the tree with objects implementing the TreeNode interface. As I have no access to the sources of named 3rd party library I have to wrap the objects I get from the library with another object implementing TreeNode to fulfill the contract. This makes the implementation a little bit more complex and increases memory consumption as I definitely would have to deal with two objects per node.
o) node selection
The current tree keeps track of selected nodes as does Swing JTree and there are events emitted when selection changes as there is a possibility to register listeners interested in this kind of events. If I did not miss something there is no such functionality in tree2. In fact I do not have a proposal at the moment on how to implement it, but that's an important feature from my POV and we should not tell the user to find a way on his own on how to deal with that.
o) node rendering rules
In fact I had the first point in mind here: if the node objects do not have to implement TreeNode then there is no way to use getType() to decide which facet to use to render a node.
Hope I was more specific this time.
Oliver
Sean Schofield wrote:
- I don't like how you changed the way the data is handed over to the
tree by forcing the user to provide TreeNode implementors? To use
TreeModel in swing was a wise decision of the designers at sun as it's
an interface which can be implemented for any kind of hierarchical data
in a simple and lightweight manner. That's why I duplicated it in my
tree impl. In you model I would be forced to wrap all my internal node
objects with a TreeNode implementor because I'm not able to change the
internal node objects as they are provided by a 3rd party library. It
can be done but in comparison to the TreeModel implementation I have in
place at the moment it's a more complex and more heavyweight solution.
And I don't like to have to ask my boss to buy better machines and more
RAM because instead of one object per node now I have to create two of them.
I don't quite understand your objection. The new approach to the data
is similar to the old except simpler. Yes the data will have to be in
TreeNode objects but that's true in the current tree and its true in
Swing. Take a look at your tree.jsp example. You are putting the
data in DefaultMutableTreeNode which extends your TreeNode interface. In my example you put the data in TreeNodeBase which extends my
TreeNode interface. OK so you have to change your data population
code slightly but that doesn't seem to be what you're complaining
about.
In both versions of the component (and in Sun's JTree) you have to put the data in an object that implements a TreeNode interface. The new tree is no different. In fact, the interface is simpler. I don't understand the third party tool argument. Do you really have third party tools that are returning objects that implement org.apache.myfaces.custom.tree.TreeNode? If not, then what do third party objects have to do with anything?
I will play Devil's advocate for a moment and say that the best
argument against the new tree is that you might have to make slight
changes to your code so that your are populating TreeNodeBase (or you
own custom TreeNode) instead of whatever your were populating before. A non trivial change but IMO well worth it to get the new features of
the new tree. You definitely do not have to have two sets of objects
or buy more RAM.
- tree2 is not able to deal with node selection so anybody would be on
his own to implement this feature; I think there should be a way to have
the tree handle node selection
I'm not sure how to respond to that. Tree2 handles node selection perfectly fine IMO. What do you mean by this? What is it not able to do that you need it to be able to do? The nodes open and close when you click on them. It works in javascript or through server post. It remembers which nodes are open. And you can put pretty much any JSF component in the node (checkbox, image, commandLink, radio buttons, whatever) and it handles the events appropriately.
- your scheme of defining how the nodes are rendered is nice and simple,
but it will not work out for some of the scenarios I have to deal with;
so we have to find a more powerful way to specify rendering rules
I'd be interested in hearing what kinds of scenarios this scheme
couldn't handle. Perhaps you there are some but if the component can
be improved by understanding your scenario then I'd like to know. Both you and Heath have thrown some intersesting scenarios my way in
the past and I think I have adressed them (and the component is better
for it.)
Oliver
sean
-- Oliver Rossmueller Software Engineer and IT-Consultant Hamburg, Germany http://www.rossmueller.com
