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
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
I don't have a real life use case for 3000+ nodes, so your insight (and
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