I don't have much thought on the matter, but I've been using the "experimental tree2" component, and it works great! Mind you, I don't have a complicated web application and using the TreeModel in the session scope works FOR ME, it might not be so for others.
regards Edwin On 8/5/05, Sean Schofield <[EMAIL PROTECTED]> wrote: > 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/ > > > > > > >
