> None of your components, tree or tree2, is better than the other one. > Both are excellent components with perhaps different features.
Agreed. When Oliver and I started this process we agreed that there was room for improvement in the current tree control. I think we've made some of those improvements. > So, please: Is there any realistic chance to merge these two into one > super tree component that has every single feature of both worlds? That has been my goal all along so I am ok with that. I have been asking for feedback on the user list asking users to try out the new tree and let me know what issues there were (including missing functionality from the current tree.) So far the big thing that has come up is that there is a companion tree table control that depends on the current tree control. So right now I am working on making a tree table that is compatible with the new tree control. > - 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. Both are already similar (but not identical) to the Swing interface. The changes to the new tree interface are small but crucial so there's not a lot of wiggle room there. There are a few things I took out because they are no longer needed and a few things that have been added because they are now needed. Ultimately I think the interface depends on your approach to solving the problem. > - 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. I think we have this already. I will double check to make sure all relevant files have the appropriate author tags. (Side note: I'm not sure author tags are allowed for top level Apache projects. When Struts changed from Jakarta to Apache we had to remove all of the author tags.) > - 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. I agree 100% with this. Also, noody forces the user to upgrade to the next version of MyFaces. The end user controls the timing of this. Our users also have the opportunity to influence the outcome of the new control through participation on the mailing list. > 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. I remain open to criticism. The more specific the better. The new tree has benefited already from the suggestions/criticisim of Oliver and others. I promise not to take it personally. > 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. My biggest issue in the current tree is lack of javascript support. Every time you click on a node you have to post to the server. This makes the tree very slow. Oliver has pointed out that sometimes the size of a tree is too large to render completely on the client and thus a tree has to support the server expansion method. I agree with him on that, so the tree should support both (which I have done in the new tree.) Javascript support on the client is a must have. My second issue in the current tree is the complexity in both its design and configuration. I found it to difficult to setup a simple tree for myself that did what I needed. I have a use case where I need to specify different types of icons depending on the nature of the node that is being rendered. I think a solution that relies on facets, commandLinks, value binding expressions and other familiar JSF concepts is easier to use. Finally there appears to be limitations on what can go in a tree. It would be nice if the tree could accept any kind of JSF component as the node and for all normal JSF behavior to work for those components. ex. You could add an inputText component to nodes of a certain type and have listeners for ValueChangeEvents, etc. Basically give the user complete flexability on how the tree can be rendered and what can go in the tree. > 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. Sounds good. > 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. I have been trying my best in this area but there is always room for improvement. I like to consider myself a team player. > If everybody stays fair, I'm sure we could have a one-for-all kick-ass > MyFaces tree component. Yes! > Manfred sean
