@Mathias, Looks good. I made a few tweaks (mostly formatting changes) and committed. I also changed the examples back the way they were before the model change.
I like your idea of optionally persisting the TreeState. At some point, I may want to update one of the simple examples and have this point to a bean with session scope so we can show users how this option works. The expandAll problem is an interesting one. What do you think about the TreeState having a ref to the model? This would seem to be necessary if you wanted to update the state through the TreeState class. Another possibility is moving this method back to TreeModel which could iterrate through the list of all nodes, and call toggleExpanded on the TreeState. I kind of prefer this approach as it leaves the two decoupled. @Dennis, We can look into the "n level" deep issue once we solve the more general expand all problem. @Everyone Feel free to test the nightly build to make sure everything still works the way you wanted. The only thing that won't work at this point is the expandAll. sean On 8/9/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Hi Sean, > > well I couldn't resist it. I have created a patch that includes most of my > ideas. > It was a fast hack, there may be new bugs with it. > > Most of the changes are in UITree.saveState, UITree.restoreState and > UITree.getDataModel ... now it is again possible to only supply a root > TreeNode. > I put the state functions into TreeState. Unfortunatly the new expandAll > functions do not work, because they are coupled closely with the model. > To make them work again we would need a reference to the model in that > functions and a function like String getNodeId(TreeNode n) in TreeModel. > > Tell me what you think... > > > > Regards, > Mathias > >
