Manfred,
I don't know what was wrong with my post or with Sean's reply that caused you to write this message, but anyway I sign 99% of it's content. The 1% I can not follow completely is the point according interface changes. From my POV we have to be careful in changing existing components. If you are in the middle of a project you care about any change in a framework you are using. To say it's up to the user to update to a new MyFaces release or not is only half of the truth. Consider there is a bug in MyFaces which blocks an important feature of your application and which will be fixed in the next release. Where is your choice in this situation? As you urgently need the fix you have to update. And now consider that by updating to the next release you also get a a new tree/tabbed pane/navigation/... component which offers the same or better functionality as the old one but by using a different interface or programming model so that your existing code will break. You don't care about new and better functionality in this situation, you just want the fix to finish your project. So what would your opinion be in this situation. I suppose you would not be too happy the MyFaces developers force you to change a crucial part of your application?
To make it short: there is no problem in changing components and their interfaces as long as the changes are small and straightforward and require only slight modifications by the user. In any other case we should continue to support the old component (by providing a legacy package for example).
Oliver
Manfred Geiler wrote:
Oliver, Sean,
I do not understand every single issue in your current discussion, but what I see is some danger in the direction your discussion is heading for at the moment. Please, both, lean back for a few seconds. "My stuff is better" discussions are always counterproductive and often end with one party giving up and saying "goodbye". That is what nobody wants. MyFaces needs both of you!
None of your components, tree or tree2, is better than the other one. Both are excellent components with perhaps different features.
So, please: Is there any realistic chance to merge these two into one super tree component that has every single feature of both worlds?
When I say merge, I mean:
- Consolidate the abstract view (the interfaces users would implement). In doubt, let's do it the Swing way. This is what people already might know and are familiar with.
- All interfaces and classes that are at least similar in function in both components must have both author tags. Might sound childish, but it is not. Everyone of us is proud of the code he has hacked. And that's ok. So, please be fair and reference the other author when you had equal ideas or where influenced by the other's code.
- No fear to change interfaces or behaviour if that makes things simpler for everyone. Yes, people might already use the old tree component. And they will have to change their code. But nobody will have a problem with that, if the gain is a new all-in-one super tree component. On the contrary, nobody will be happy in the long run with two nearly-equal but competing tree components.
Oliver, please be fair to Sean and tell him every single issue, you think is missing or sub-optimal in tree2, in a clearly laid out and businesslike manner.
Sean, please be fair to Oliver and tell him every single issue, you think is missing or sub-optimal in tree1, in a clearly laid out and businesslike manner.
Ok, I'm not starry-eyed, so please, both of you, whenever there is an issue, where you do not see any chance for an agreement, stay fair and please take the effort, describe the problem, so that also non tree experts have a clue, and let us vote about it.
And always have in mind that written words are subject to misinterpretation more than spoken words. We are all no well-trained diplomats, so our language might sound rough sometimes, although not meant so. Please have this in mind and always assume, that the other party meant it businesslike, also if it sounds affective.
If everybody stays fair, I'm sure we could have a one-for-all kick-ass MyFaces tree component.
Thank you guys, Manfred
Sean Schofield schrieb:
- 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
