[offlist] End of the Road (Was Re: Tree2)

[Sean Schofield <se...@gmail.com>]

Oliver,

You continue to embarass yourself with these ranting email messages. 
Up until this point I have been *more* than patient with your antics. 
I have tried over and over again to be diplomatic with you about this.
 I understand that you put a lot of hard work into the original tree
control and I have tried to be sensitive to that fact.  I approached
you privately off the list to see if your were willing to work
together on this.  If I had known how you would have handled this back
then I would never have bothered.

The fact of the matter is that the current tree control is unworkable
for me.  I tried working within its existing code base but I found
that to be impossible.  I tried soliciting your opinion but after a
few posts you dropped out of the conversation entirely only to emerge
when the component was complete and not to your satisfaction.

You have been extremely dismissive of the new tree control and all of
the hard work that myself and others have put into it.  You continue
to insult me with your posts that imply that I am too much of an idiot
to understand you.  Believe me, I get it.  You are the only one who
knows how to write a tree control.

I learned a long time ago that the key to good software development
was teamwork.  Each programmer brings something to the table and the
best software tends to draw on a synthesis of those ideas.  I took
this approach when developing the new tree control and included some
of your ideas along with those of others.

It is clear to me that you do not have any interest in working
together anymore.  Manfred (and others) have pleaded with us to work
this out.  You refuse to move even an inch.  You refuse to concede
that there is any merit to a new tree control.  You have insulted both
myself and my ideas.

Well I am personally tired of banging my head into a wall on this.  I
have more important things to do with my time.  I think the new tree
control is great.  It has 99% of the original tree functionality with
a ton more features.  And its much easier to configure and uses half
the amount of source code.  If you were willing to work with me on it
you could have had 100% of the current tree functionaltiy.

So my plan is to use this in my own program.  If MyFaces still wants
the new tree then I will be happy to provide the documentation and
support.  I think its kind of silly to have two trees but if everyone
thinks that is a good copromise then I will go along.  I have one
request which is that we resolve this quickly.  I need to know whether
I should stop with my open source efforts on this particular component
or not.

Lets put this tree argument to rest once and for all so we can move
onto more productive matters.  We have a lot of top level project
tasks to be handled and a new release of MyFaces coming.  The tree
control is only a small part of a much larger project.

Since Manfred is our leader on this project I will defer to him as how
we best go forward.  As I mentioned to him a few weeks ago, I am
willing to withdraw my code or to have two tree components.  I am
willing to have an informal or formal vote.

Regards,
sean







On Mon, 14 Mar 2005 02:15:23 +0100, Oliver Rossmueller
<ol...@tuxerra.com> wrote:
> Sean,
> 
> you do not accept my argument that the wrapper objects I would need
> following your programming model waste memory. That's fine for me. But
> tell you what: I do not accept your argument that implementing TreeModel
> is a special case nobody else is using. My colleagues and I have
> implemented TreeModel variants for dozens of Swing applications to save
> memory resources. Of course you can do without your own implementation
> by using DefaultTreeModel. But - accept it or not - memory consumption
> matters for some people out there. So don't wipe this argument from the
> table like it's not there.
> 
> I'll tell you how we are going to resolve this: when you came along with
> the idea for an improved tree component I told you we can get all the
> requirements you are looking for by refactoring the existing tree
> component. You choose the revolutionary approach and started your own
> component from scratch. That's just fine for me but now I'm going to try
> the evolutionary approach by refactoring the existing tree and
> incorporating new functionality from tree2. I'm quite sure this can be
> done without breaking existing code. As I have other stuff to work on,
> too, this will not be finished within the next few days. Anyway it
> should be worth the time as we'll end up with one tree component and
> without the need for a legacy package.
> 
> In the meantime if there will be a MyFaces release we should mark tree2
> as experimental and tell anybody that he's using this component at his
> own risk.
> 
> Oliver
> 
> 
> Sean Schofield wrote:
> 
> >Oliver,
> >
> >You are correct that option 3 is missing in the new tree and that its
> >present in JTree and the current tree.  This was not designed to
> >intentionally deprive you of functionality that you need in your
> >application.  It didn't really occur to me that tree should support
> >this kind of functionality.
> >
> >You must admit that your situation is a pretty specialized case.  How
> >many MyFaces users are using third party components that provide tree
> >data via a model?  My guess is that most are pulling the data
> >themselves from LDAP or a database and they are using either options 1
> >or 2 which tree2 can handle.
> >
> >You are basically asking for the ability to plug a third party data
> >model directly into the tree without wrapping the objects with an
> >adapter, etc. to conform to TreeNode interface.  I definitely think
> >that it is acceptable to wrap your data with a very *light* object
> >that can provide this functionality.  I do not accept your argument
> >that this wastes precious memory.  The adapter pattern is a standard
> >practice and is done all the time without crashing servers.  I agree
> >that in your case it would be a hassle to change the code but lets not
> >overstate the ramifications of this solution.
> >
> >Your code sample where you show how you could use tree2 right now
> >seems perfectly fine to me.  I recall that you are using the
> >server-side expansion control now because you have too much data to
> >push to the client at once.  This makes the wrapping of your
> >components even less burdensome.
> >
> >Since there seems to be some concern about losing this functionality,
> >I would propose that we consider keeping the original tree but moving
> >it to a legacy package name and give it a tag like <treeLegacy>.  Also
> >we should deprecate the current tree classes.  Since it looks like a
> >release will be coming soon I think this is the best short-term
> >solution.
> >
> >Then you and I can explore the possibility of providing option 3
> >functionality in a future release.
> >
> >What do you think about that?  I take it you have no other concerns at
> >this point other than option 3 functionality.  Is that correct?
> >
> >sean
> >
> >
> >On Sat, 12 Mar 2005 14:22:55 +0100, Oliver Rossmueller
> ><ol...@tuxerra.com> wrote:
> >
> >
> >>Sean Schofield wrote:
> >>
> >>
> >>
> >>><snip>
> >>>
> >>>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.
> >>>
> >>>
> >>>
> >>>
> >>The point is not JTree but the options the user has in providing data:
> >>
> >>Option 1: Use DefaultTreeModel and wrap your node objects using
> >>DefaultMutableTreeNode
> >>
> >>Option 2: Use DefaultTreeModel and have your node objects implement
> >>interface TreeNode
> >>
> >>Option 3: Implement interface TreeModel on your own
> >>
> >>As the current tree component's design closely follows JTree you have
> >>the same three options:
> >>
> >>Option 1: Use DefaultTreeModel and wrap your node objects using
> >>DefaultMutableTreeNode
> >>
> >>Option 2: Use DefaultTreeModel and have your node objects implement
> >>interface TreeNode
> >>
> >>Option 3: Implement interface TreeModel on your own
> >>
> >>Now you say we do not need option 3 anymore, so tree2 only has
> >>
> >>Option 1: Use TreeNodeBase to wrap your node objects
> >>
> >>Option 2: Have your node objects implement interface tree2.TreeNode
> >>
> >>As you kicked away the TreeModel interface (your TreeModel class is just
> >>an implementation-specific internal helper for HtmlTree as I see it) I
> >>no longer have the option to implement TreeModel on my own. But named
> >>option 3 is a crucial option and it's absence is an absolute show
> >>stopper for me. As words seem not to work out in explaining my argument
> >>I'll try it with an example this time. It follows the scenario using the
> >>3rd party library already mentioned before.
> >>
> >>So at the moment I have an implementation of interface TreeModel which
> >>looks somewhat like the following:
> >>
> >>public class MyTreeModel implements TreeModel
> >>{
> >>
> >>   private ExternalLib externalLib = new ExternalLib();
> >>
> >>   public Object getRoot()
> >>   {
> >>       return externalLib.top();
> >>   }
> >>
> >>   public Object getChild(Object parent, int index)
> >>   {
> >>       ExternalObject[] children = externalLib.subnodes(parent);
> >>       return children[index];
> >>   }
> >>
> >>   public int getChildCount(Object parent)
> >>   {
> >>       return externalLib.countSubnodes(parent);
> >>   }
> >>
> >>   public boolean isLeaf(Object node)
> >>   {
> >>       return externalLib.testLeaf(node);
> >>   }
> >>
> >>   public int getIndexOfChild(Object parent, Object child)
> >>    {
> >>        ExternalObject[] children = externalLib.subnodes(parent);
> >>        for (int i = 0; i < children.length; i++)
> >>        {
> >>            if (children[i].equals(child)) {
> >>                return i;
> >>            };
> >>
> >>        }
> >>        return -1;
> >>     }
> >>
> >>   public void valueForPathChanged(TreePath path, Object newValue)
> >>   {
> >>       ...
> >>   }
> >>
> >>   public Collection getTreeModelListeners()
> >>   {
> >>       ...
> >>   }
> >>}
> >>
> >>Simple enough, isn't it? But you tell me I can't use TreeModel anymore
> >>when using tree2. So any node object has to implement tree2.TreeNode. As
> >>I have no  access to the sorces of ExternalLib and ExternalObject and
> >>therefore can not implement interface tree2.TreeNode in the library I
> >>have to use a wrapper. Unfortunatelly I cannot use option 1 ans
> >>TreeNodeBase just operates on strings. Ok, so I have to implement
> >>tree2.TreeNode on my own:
> >>
> >>public class TreeNodeWrapper implements TreeNode
> >>{
> >>   private String identifier;
> >>   private ExternalObject node;
> >>   ExternalLib externalLib;
> >>
> >>   public TreeNodeWrapper(ExternalObject node, ExternalLib externalLib)
> >>   {
> >>       this.node = node;
> >>       this.externalLib = externalLib;
> >>   }
> >>
> >>   public boolean isLeaf()
> >>   {
> >>       return externalLib.testLeaf(node);
> >>   }
> >>
> >>   public void setLeaf(boolean leaf)
> >>   {
> >>       // don't know why this is in the interface
> >>       throw new UnsupportedOperationException();
> >>   }
> >>
> >>   public List getChildren()
> >>   {
> >>       ExternalObject[] children = externalLib.subnodes(parent);
> >>       ArrayList answer = new ArrayList(children.length);
> >>
> >>       for (int i = 0; i < children.length; i++)
> >>       {
> >>           answer.add(new TreeNodeWrapper(children[i], externalLib));
> >>// <= EXTRA OBJECT HERE ###############
> >>       }
> >>
> >>       return answer;
> >>   }
> >>
> >>   public String getType()
> >>   {
> >>       return node.getTypeName();
> >>   }
> >>
> >>   public void setType(String type)
> >>   {
> >>       // don't know why this is in the interface
> >>       throw new UnsupportedOperationException();
> >>   }
> >>
> >>   public void setDescription(String description)
> >>   {
> >>       // don't know why this is in the interface
> >>       throw new UnsupportedOperationException();
> >>   }
> >>
> >>   public String getDescription()
> >>   {
> >>       return node.getLabel();
> >>   }
> >>
> >>   public void setIdentifier(String identifier)
> >>   {
> >>       this.identifier = identifier;
> >>   }
> >>
> >>   public String getIdentifier()
> >>   {
> >>       return identifier;
> >>   }
> >>
> >>   public int getChildCount()
> >>   {
> >>       return externalLib.countSubnodes(node);
> >>   }
> >>}
> >>
> >>All right, complexity of this implementation is similar to the TreeModel
> >>implementation. But my main argument against your decistion to drop
> >>option 3 is the need for extra wrapper objects to fulfill the conctract
> >>(see method getChildren() above where any ExternalObject has to be put
> >>inside another wrapper object). Maybe you do not care about resource
> >>consumption but I do and I have to because the machines I have at hand
> >>are kind of limited in that aspect. So I don't like to be forced to
> >>waste memory just because you do not like the TreeModel interface and
> >>the programming model behind it. You say it's just an interface but you
> >>have to see the implications on possible implementations this change in
> >>interfaces has. That's what I'm talking about all the time.
> >>
> >>So please give option 3 back to users and change tree2 to take
> >>tree.model.TreeModel instances as it's value instead of tree2.TreeNode.
> >>Or show me a way to fulfill the tree2.TreeNode contract without the need
> >>for extra objects in the example above.
> >>
> >>Oliver
> >>
> >>
> >>
> >>>
> >>>
> >>>
> >>>>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
> >>>
> >>>
> >>>
> >>>
> >>--
> >>Oliver Rossmueller
> >>Software Engineer and IT-Consultant
> >>Hamburg, Germany
> >>http://www.rossmueller.com
> >>
> >>
> >>
> >>
> 
> --
> Oliver Rossmueller
> Software Engineer and IT-Consultant
> Hamburg, Germany
> http://www.rossmueller.com
> 
>