The new implementation has a major problem: now I am required to supply a session scoped
TreeModel, because the model and therefor the expand/collapse state is not saved with the component.
I supply a request scoped TreeModel. The problem is now: I can expand one node and after that all the expand state
is lost an I start with an initial tree. That makes the tree unusable for me with multiple windows of the same page (with client state saving).
I cannot provide a session scoped model because that would sync the tree in all windows.
I think the expand state is something that belongs to the component state, not to the "model state".
Sean you already mentioned this in a post.
[EMAIL PROTECTED] schrieb am 04.08.2005 22:20:02:
> More progress on Tree2. After a lively debate (with myself) I have
> decided (for the moment) to require and instance of TreeModel for
> @value. This will break current JSP pages using tree2 so I suggest
> tree2 users follow this thread closely. You have been warned!
>
> The advantage of maintaining the expanded state in the TreeModel
> outweigh the minor hassle of adding a TreeModel foo = new
> TreeModelBase(oldFoo) to your code to get it to work. (Note: oldFoo
> would be the root TreeNode that was previously used for @value.)
>
> Given the likely dynamic nature of the data underlying the model, this
> new approach makes sense. If a node is added (or dropped) in the
> model, the expanded state (and eventually selected state) can also be
> modified accordingly. The HtmlTree is absolved of all responsibility
> in this area so if your expanded state is wrong, it will be the user's
> fault. Now users can specify the expanded state in their own
> implementation of TreeModel. I've also added a setExpandAll method to
> TreeModelBase so that you can specify all of the nodes to start off
> expanded. So no more talk of tree3 please :-)
>
> Feedback is welcome. I'm checking in the code momentarily.
>
> Regards,
>
> sean
