Sean Schofield wrote:
I don't not get the reason for why you are throwing away TreeModel for TreeNode.maintaining the expanded state adds a requirement to the node objects
that is not necessary from my POV. This is pure presentation stuff so
why should we annoy the implementer of the model with that kind of
things. In fact it would be nice to use the 'rendered' attribute. But if
the consequence is that I have to deal with presentation stuff in the
model than it's a -1 for me.
We definitely need to get a CVS branch going so that I can show you my code as we have these dicussions. I think there is some confusion between how we are using terms such as "model."
For now I will try to explain briefly how I am using these concepts in
the new code. I have a TreeNode interface that is similar to yours. Like yours it has a setter and getter for the "expanded" property. The idea is that the developer builds their tree with a series of
nested TreeNodeBase objects (or some other class that implements
TreeNode). So the "root" node is what is bound to the HtmlTree
component via the "value" attribute. The user does not supply a
TreeModel, just this simple collection of nodes.
Behind the scenes, HtmlTree will wrap the provided TreeNode data in a
TreeModel interace. (I think this part is different than your
implementation.) This is similar, however, to what happens in
dataTable. The TreeModel just provides a few extras that we don't
need to concern the user with.
But ok, I'll wait for your code so we have a common base for further discussion.
I do agree that ideally the expansion state of the node should not be part of the "model" (using the term model here to refer to the concept of an object that contains data). I compromised on this idea some after seeing Bergsten's example. The developer is still not in charge of setting the expansion state, its just in the TreeNode interface so that it can be used by the rendered attributes as I described. The HtmlTree actually takes care of setting the expansion value.
In light of your recent suggestions, however, I think I can improve upon this even more so that neither TreeNode nor TreeModel need to concern themselves with this. (See next email for details.)
Just because it's in Bergsten's book makes this no better to me.
I did not mean to imply that because I read it in a book that we have to it that way. For starters Bergsten's example is a book example and will by its nature be a bit oversimplified. But I do mention his example for a couple of reasons (besides the fact that he is part of the JSF expert group.) The first is to provide a resource for people following along with these discussions. The second is that he has encountered and solved many of the problems that I discovered while tring to do this myself. (It also appears that he worked on the RI implementation of <h:dataTable> b/c the source for that is remarkably similar.) We would be foolish to ignore his experience in this area (which is not what I think you are suggesting.) That being said, we are of course free to pick and choose what ideas of his we use and which we do not. I have already modified his example extensively.
The condition part of a rendering rule as proposed is just optional and
can be used for more complex rendering logic. I think the rule syntax is
quite straightforward and even more explicit than the proposed facet
naming scheme. Even if you are not familiar with the tree component you
will get an understanding of what happens.
Are you opposed to the facet naming scheme? I personally think its a good idea. If you we can address your concerns without removing the facet scheme would that be ok?
Besides, if you don't like IconProvider and don't like rules and
conditions, too, so where in the new tree should I place my icon logic?
Its not that I don't think these ideas will work. I am just striving to keep it as simple as possible with as few new tags as possible. I think I can ultimately address your icon logic concerns. (See next email)
I'm also currious about how the client-side node expansion will work. I
suppose we have to render the complete tree from the root node down to
any leaf to some kind of javascript datastructure you can deal with in
the browser. So how does the icon logic fit in there? And how will the
client-side tree state be synchronized with the server-side tree
component state?
I have a plan for this. I will provide more details shortly. It turns out that the server-side logic is easier to implement so I am starting there (even though client-side logic is one of my main requirements.)
Oliver
sean
-- Oliver Rossmueller Software Engineer and IT-Consultant Hamburg, Germany http://www.rossmueller.com
