> What do you mean by not getting saved? If you mean its not saved as
> part of the state, you are correct. TreeModel is serving as a wrapper
> for the data which is stored in TreeNodes. Its kind of like a facade
> to the data - helps the user to "walk" the hiearchy of the data.
>
> The getNode method in UITreeData is return the "curent" node. It
> essentially pass the call to getNode in TreeModel. Its used by the
> renderer to determine the current node and render it.
Yes, thats what I talked about. So TreeModel is essentially a helper to access the TreeNodes.
> Its been a while since I looked at this aspect of tree2. I can't
> remember why the TreeNodes are saved with the component state. I'm
> not sure that we really want this behavior. Since the value attribute
> is a method binding, I'm thinking we should only be saving the
> _expression_ (not the actual tree nodes.) I will look into this
> further.
Ok, I see your point. Saving a huge number of nodes only to remember their state is not the solution we want.
I think then the component should not save the model data. But is that really done? As I understand the code, the "value" is only saved with the state, if it is directly set by code on the component. If I use a value binding, then only the binding is saved automatically.
I tested it with some dummy nodes and the hidden input in the form does not get noticeably larger.
> I debated storing the expand/collapse state with the nodes themselves
> (I believe that is how its done in the original tree.) My thinking
> was to keep TreeNode as a pure representation of the data.
> Expand/collapse is really an HTML or rendering concept so the thinking
> was to handle that in HtmlTree.
From that point of view, it makes sense.
> This is actually one of the major decisions that needs to reconsidered
> when talking about supplying your own TreeModel. If we move the
> expand/collaps to TreeNode then this requires that all TreeNodes be
> persisted (in order to preserve the expand/collapse state.) While
> that might be happening now, that was not my intent. For large
> server-side expansion solutions (with 3000+ nodes, you don't
> necessarily want to preserve the entire set of nodes just because 3 of
> them are "open.")
Decoupling the expand/collapse state form the nodes leaves two options as you pointed out:
- Let the component handle that, how it is currently done. Then the component would need some new methods for manipulating the state. I also would like to reuse the "view" state of the tree. I guess then I will have to bind the component to a session scoped bean and reuse the whole component on different views, but I have not tried that yet.
- Save the expand/collapse state of the tree with the model. This has the benefit, that the code manipulating the state is more bound to the model than to the component and the model/state would be reusable with a session scoped bean. But JTree for example does not follow this idea (I think). Then the model would have to be saved with the state of the component (without the nodes).
> I went back and forth on the feature. This was just left over code
> that should have been removed.
The problem I see is, if the state is not stored in the nodes, how is the state mapped to the nodes if the tree structure changes. How did you solve the problem? I read something about a index.
My idea would be to do that with a ID of each TreeNode. There is already a getter/setter pair for this but is is completly unused. Every TreeNode would have to return a ID - explicitly set or a generated hash. That would make it possible to map the stored state (in model or component) to the right node.
> I don't have a real life use case for 3000+ nodes, so your insight (and anyone else's)
> into how a user-supplied tree model would work would be helpful.
At the moment I don't have a real use case with 3000+ nodes, too. My current TreeNode implemenation dynamically resolves its child nodes. Storing the nodes in the state would make no problem regarding size, but it would be difficult to save a user defined expand/collapse state. In general I guess it would problematic to save the state with dynamically generated nodes.
