Antwort: Re: [tree2] Problems with new TreeModel interface (need help!)

[mathias . werlitz]

Well my thoughts:

Supplying a custom TreeModel may make sense, but as we found out it should not cover the
expand/collapse state of the component. A sperate state manager seems to be appropriate. But this manager
has to be saved with the state of the tree. It would be nice to control this behavior. If the user wants not to save the state (because of a session-scoped model and manager)
he could turn off the sate saving of the expand state (kind of isStateManagerTransient()). The model does not need to be saved.

One idea maybe to be able to provide the state manager along with the model. This would make it possible to provide
a custom state manager - some kind of getStateManager() in the model. Everytime the state manager is restored the model could be updated with state (setStateManager). Than the model may update the state. This method should not be called if the state is transient in the tree.

I think this would make it even possible to switch back to the old behaviour to provide only the root node.
The tree then internally creates a default model and a state manger that is saved with the state of the component.
The tree should provide a method for getting the model.


- It would also be nice to have a method to expand a node and all parent nodes to make it viewable.
- I extended the default TreeNode to supply a user object. This could be included in the default node.
- I still wonder what the ID of the node is for. If we require each node to return a real id that may solve
problems while updating the state if the model changed. This would open an alternative way of sync of the state for the nodes.
They could be identified by the id not by the path in the tree.

- It would also be nice to be able to provide a default facet for "unknown" type of nodes or at least not rendering the node.