Don't panic. I'm still just exploring ... I agree with you Mathias that requiring a session-scoped model may be problematic. Its definitely a drawback ...
One possibility is the user supply an optional state manager to keep track of expanded state information as well as node selection. This would allow request scoped models. I'm not wild about it, but it would seem to solve the problem. What other suggestiosn do people have to solve the original problem? (ie. Give users more flexability in controlling these aspects.) I didn't get much feedback from the tree2 summit post on the dev list but clearly there are some opinions out there :-) I will be off for the weekend (and I will mull this over.) Give some thought and post your ideas here on this thread. sean On 8/5/05, ir. ing. Jan Dockx <[EMAIL PROTECTED]> wrote: > Please please please don't make tree2 depend on a treemodel being kept > in session scope. We are working hard to get a framework that depends > on only minimal data in session scope, e.g., for tables, since storing > large datamodels (> 10 objects with many concurrent users, > 100 > objects with less many concurrent users, etc) in session scope is > obviously unsustainable. Now if treemodel needs to reside in session > scope, we will have the same trouble all over again. > > It is ok for the Node interface to have methods to easily access the > current component, but expande state etc. really should be stored in > the component, and not in the model. The methods in the model should be > regarded as shortcuts to access the state in the current component. > > This is consistent with the philosophy of MVC: this is view state, and > belongs in the component, and not in the model. E.g., also, you could > have 2 tree's that show the same treemodel, with different view states. > > > On 4 Aug 2005, at 22:20, Sean Schofield wrote: > > > 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 > > > > > Met vriendelijke groeten, > > Jan Dockx > > PeopleWare NV - Head Office > Cdt.Weynsstraat 85 > B-2660 Hoboken > Tel: +32 3 448.33.38 > Fax: +32 3 448.32.66 > > PeopleWare NV - Branch Office Geel > Kleinhoefstraat 5 > B-2440 Geel > Tel: +32 14 57.00.90 > Fax: +32 14 58.13.25 > > http://www.peopleware.be/ > http://www.mobileware.be/ > > >
