I would opt for creating very simple Java beans containing the cached information and store them on the session and later on use that information to build the menu bar. If several users share the information (e/g/ based on roles) maybe you can devise some mechanism to store them by "role" so that several session share the information. If this "menu bar" information does not vary over time, or you have a good criteria to know it is stale, and if is costly to compute I would also consider (as you suggest) storing it on a temporary database for later use (and recompute it just if it is stale).
Best, Ernesto On Wed, May 5, 2010 at 3:55 PM, 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]
