Oliver,
> I'm sorry but I feel somewhat like talking to stones at the moment :-(
> I'm repeating myself over and over again but you just seem to ignore my
> argument that TreeNode is nothing more than a helper interface to
> support the Swing JTree component. Please have a look at the sources if
> you don't beleave me but JTree is operating on a TreeModel instance and
> TreeModel operates on any kind of objects not just TreeNode instances.
> JTree is not relying on the node objects implementing any specific
> interface, nowhere! The same is true for the current tree component. In
> my opinion TreeModel is the more flexible, lightweight and
> resource-saving approach and so far I did not get an idea what your
> argument is against TreeModel and for TreeNode. Your decision to force
> the user to implement TreeNode for all of his node objects is no
> improvement but a step backwards from my POV.
Yes you are repeating yourself over and over on this point. I do not
see how tree2 has changed the basic requirments of the user. You keep
saying that I am against TreeModel and for TreeNode. That is not the
case. Let me try to phrase my argument differently ...
You are correct that JTree operates on a TreeModel instance. It also
has TreeNode interface. Data is first wrapped in TreeNode instance
before being added to the model. See this example from Sun's JTree
example:
rootNode = new DefaultMutableTreeNode("Root Node");
treeModel = new DefaultTreeModel(rootNode);
treeModel.addTreeModelListener(new MyTreeModelListener());
tree = new JTree(treeModel);
You are correct that JTree does not require a TreeNode interface. I
agree with you there. JTree does require a *different* interface,
however, and that interface is TreeModel. You cannot just add some
arbitrary String "Foo" to a JTree. How would the tree know what to do
with it? Is this string a leaf or not? How can you add children to a
String? You have two choices. First choice is to use
DefaultMutableTreeNode and DefaultTreeModel (as shown above.) That
option *requires* TreeNode. Second choice is to write your own class
that implements TreeModel. Either way, you cannot just add an
arbitrary String to a JTree.
Again, I urge us not to think in terms of JTree. Lets leave JTree out
of this for now. Lets just talk about the shortcomings of tree2. If
we can address those then we can move forward. IMO discussing JTree
is not helpful in reaching consensus on this.
> Exactly that's my argument: the TreeNodeBase instance is the extra
> object you force me to create!!! When implementing TreeModel there is no
> need for this extra object, I'm able to use just the 3rd party data
> objects, naked and unwrapped as I get the from the external library. I
> don't have to wrap them with DefaultMutableTreeNode or any other object.
I guarantee that your third party component is not returing objects
that implement TreeModel. That is my point. I think you are getting
hung up on the wording of TreeModel vs. TreeNode. The current tree
needs to make the raw data compliant with what the component expects
(TreeModel). The new tree does the same thing but calls it something
different (TreeNode.) The current tree also has a TreeNode interface
and you say that its not required to use the tree. That's fine. I
won't argue that point.
To summarize, the current tree requires that data be adapted to the
TreeModel interface. The new tree requires that data be adapted to
the TreeNode interface. The fact that I am calling it TreeNode
instead of TreeModel does not make it any more difficult for the user
to implement. The new tree also has a TreeModel class. A difference
in the new implementation is that the model stuff is handled behind
the scenes. There is no need for the user to provide their own model.
We could look at changing that but basically its already possible to
provide your own models by extending the TreeModel class.
Please take another look at how I am using TreeNode and TreeModel. If
you think its important that the user can provide their own models
then lets explore that! Maybe this is the nature of your objection.
If so, I'm happy to work with you on that.
I think some of the confusion is over the changes in implementation.
This is primarily a difference of opinion between the two of us. It
doesn't affect the users. Most users are going to use
DefaultMutableTreeNode as you do in your example or TreeNodeBase as I
do in my example.
> Again you seem to ignore my argument. I'm not talking about
> expanded/collapsed state but about SELECTED nodes. Take the tree example
> in the examples webapp. When you click the text of the root node it will
> get bold as the root node is the selected node now. Go on and expand
> some of the children and click the text of one of the child nodes: again
> the text will get bold to mark the selected node. At any time it is
> possible to ask the current tree for the path to the node currently
> selected. In tree2 the component itself does not care about that so I
> have to implement that feature on my own. It can be done using some
> specific command links and actions but I think to keep track of a
> selected node is a feature so common to tree components that is should
> be implemented there.
This is the kind of specific use case that I have been asking you to
provide. Until now you just kept telling me that the new tree could
not handle selection. Now I see what you mean by selection. Let me
see if I can't address it in the new tree. I will get back to you on
this one.
> Actually that's what I'm doing I suppose: to talk about features that
> are missing for tree2. But you have to be open for the fact that there
> are other scenarios and applications than the one you have in mind. I
> understand that your effort is driven by the requirements of the project
> you are currently working on. The current tree component has it's origin
> in a similar effort. To get a general-purpose tree component we have to
> address the issues I brought on the table. Otherwise we end up with two
> tree implementations which have something in common but miss some
> feature the other implementation has and vice versa. This can not be the
> goal if you ask me.
I agree we need to address these issues. In order to do that, I need
specifics. I will look into the selection issue as you have asked. I
think I can work something out on that one. As for the interface
issue, please take another look at my reasoning on that. If you want
the ability to provide your own TreeModel then maybe that's something
we can do (although I don't think its necessary.)
Believe it or not I think we are making progress. I now know what you
mean by the selection problem. So we are 50% there. Lets see if we
can't reach an understanding on the inteface issue.
> Oliver
sean
