Mathias. You've got several good ideas here. I will respond inline below ...
> 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. OK so you do see the benefit of a custom TreeModel. Currently there are not a lot of people clamoring for it but back when there was a tree vs. tree2 debate this was something that some people thought was important. I think the dynamic tree with SST would be perfect for this. Are you doing dynamic trees in your app now? If so, how are you managing it without a custom tree model? As for how the manager is saved, why does it have to be saved with the state of the tree? Couldn't this be a session bean? It wouldn't have nearly the memory footprint as storing the entire tree in the session. > 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. Interesting idea. Care to submit a patch for this? > 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. I thought about this when I first ran into the problem of the state disappearing between requests (before I made the treeBacker in the simple examples have session scope.) But I didn't think it was necessary and I was feeling a bit lazy ;-) Your subsequent post convinced me though that this will be a problem. Lazy probably isn't the right word, just busy. Could you or someone else work up a possible patch for this? People have been promising to help ... now would be a good time. > - It would also be nice to have a method to expand a node and all parent > nodes to make it viewable. Yes. This would be easier for the user to do if the state manager were a user supplied bean that was stored in the session. Perhaps if the tree could be signaled that it was time to store an updated copy of the state manager after it was modified by an event, etc.? > - I extended the default TreeNode to supply a user object. This could be > included in the default node. Not sure why this would be useful to more than your specialized needs. > - 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. Well the ID helps to identify the node when processing commands. For instance, in my app we use it to model documents and so the document number is the id. This way when the user clicks on a document to edit it, we know which document to display b/c the id is meaningful. > - 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. I guess I figured that you could always set your node type to whatever this default was. In other words, your tree population code sets the deault to "unknown" or "default" and you provide a facet with the corresponding name. So in a way, you can already do this. sean
