cache whatever holds the actual data. for example in our code we have a menu and that takes IModel<MenuRoot>, and using menu root object it can render the entire menu by traversing it. store the MenuRoot in session.
-igor On Wed, May 5, 2010 at 6:55 AM, Wolfgang <[email protected]> wrote: > > I'm working on a web site that has a menu bar with sub-items, and > sub-sub-items. The configuration of this menu is computed from hilariously > complex SQL queries and needs quite some time to be established. The menu > looks different for each user (session) but stays the same for the lifetime > of the session. So it's time for caching as this menu shows up on most of > the pages. > > From other posts on this site I've taken that it's not a good idea to share > the components that represent the menu among different pages. Now I wonder > on which level I can cache and re-use objects. > > Is it advisable to share models (in the Wicket sense), i.e. store the menu > models on the session and construct the menu components according to their > information for every page? > > Or do I have to create separate, Wicket-independent data structures that > hold the menu structure information and store it on the session or in the > database? > > Or am I on a complete wrong track and should look for caching of the > rendered HTML code on a component basis? > > Thanks in advance for sharing your knowledge/experience. > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/Cache-menu-tp2130976p2130976.html > Sent from the Wicket - User mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
