Good question that needs an immediate answer, moving to the top of the list.
Christian, please do not mess up the posts. If I see the number of posts greater than zero, my first guess - the question is answered already.
Well, it isn't and this is an FAQ. Post the answer on the FAQ list or fix the documentation.
It is not currently possible to obtain TreeNode from the UITree component because it just doesn't have them for more than half of lifecycle in some modes. It is possible to get node data only.
We're looking forward to reviewing (refactoring?) tree component in order to provide access to TreeNode instances throughout all JSF component lifecycle.
So you are saying that there is no real API to access the node a user selected in the tree? Wouldn't that make the tree component completely useless?
you've got the situation right saying there is no API for that just now. Btw, it exists, but it is an internal API so it's invisible for end-user. However I cannot agree with the point that component is completely useless. I would estimate the coverage of common user tasks as ~90%.
I agree that missing a way to find out that particular TreeNode instance causing an event, is an indisputable fault. I'm going to file a workaround for the problem in a day or two.
What are those 90% use cases? Dragging nodes around in a tree? Of course selecting a tree node and having that selection available is the primary use case. What else am I supposed to do with my tree, just look at it?
Btw, the reason why I am very impatient about this is that I've wasted _days_ on all the JSF component toolkits just to try the Tree components. They are all, without exception, unusable or at best awkward to use.
- Tomahawk Tree is pre-alpha, don't even try to understand the tree data binding, designed by beginners (rating: 0 of 10)
- Trinidad/ADF Faces Tree works from a UI perspective (at least you don't get rendering errors) but requires custom data models which are a bit weird, getting a selection from the tree is difficult (rating: 7 of 10)
- ICEFaces Tree has OK data binding concepts (using Swing TreeModel/TreeNode) but falls down in the implementation (bound to concrete AbstractTreeNode) and has so many rendering problems that it's not worth more effort (rating: 3 of 10)
- RichFaces Tree has the wrong data binding (no Swing TreeModel/TreeNode interfaces) API but at least it's understandable and small, rendering is slightly broken out-of-the-box, and getting the selection is almost impossible (rating: 4 of 10)
The Tree UI widget is a good indicator of the overall quality of a component toolkit because it has a challenging UI, sophisticated data binding requirements, and needs a good API to be useable. Right now RichFaces isn't even average on that scale.
Furthermore, a Tree UI widget is usually the first thing you are looking for in the JSF built-in components and when you realize it's not there, you start looking at the other toolkits. Think about user experience for first time users. If you search through the JSF forums, you can see that the most FAQs are about trees.
Wow, it is a good result over all for the very first version. Thank you, Christian. We are looking forward for the further improvements.
I totally agree with Christian, because that is the component I will use extensively.
I'm looking for a working tree component and haven't found one that fulfil all the requirements. Drag and Drop is one point I miss most and neigher of the frameworks seems to support that. The dojo toolkit has a nice implementation of such features but I'm looking for an JSF framework.
Would appreciate to have a nice tree component in time :)
To tell the truth I use Tomahawk tree component and don't know any problem.
For every node in my tree I use "support" component from ajax4jsf. It helpes me to add AJAX functionality in my application.It works very good, really.
But now I want to try RichFaces tree component to include drag'n'drop functionality. I hope it will work fine.
We're still being working on Tree API to make it more convinient and user-friendly. Sorry to say, but unfortunately there are no significant changes in SVN for now :(. That internal API we have for now can be opened, in principle, but there is a risk that it will be changed soon.
We've added getTreeNode() method to UITree class. You can use it to obtain the current TreeNode.