Yeah - don't stick panels or pages in session - you'll have weird bugs come up, and won't get much help here because it's not really a good idea to share components between threads.
Much better is to create a caching data model - that's what really needs to be cached anyway - the data for the component, not the component itself. Use a caching service in your service layer that gives you the reusability of a cache elsewhere in your app. -- Jeremy Thomerson http://www.wickettraining.com On Thu, Nov 13, 2008 at 11:45 AM, Igor Vaynberg <[EMAIL PROTECTED]>wrote: > oh, and of course, if you do this you are on your own as far as > threading goes inside your components. > > i still think that instead of doing this implementing a general cache > is a much better approach. > > instead of doing > tvdata tv=tvsource.getdata(); > musicdata music=musicsource.getdata(); > > restructure your business logic to work like this: > > tvdata tv=((tvresponse)datasource.getdata(new tvrequest(params)).tvdata(); > musicdata music=((musicresponse)datasource.getdata(new > musicrequest(params)).musicdata(); > > this gives you a single point of access from higher tiers (ui, > webservices, foo) and also gives you one place to cache. > architecturally this is much more sound, of course i dont know your > exact situation. > > -igor > > On Thu, Nov 13, 2008 at 9:40 AM, Igor Vaynberg <[EMAIL PROTECTED]> > wrote: > > you can simply stick a panel or page into session. alternatively you > > can override ipagefactory and implement a cache infront of that for > > bookmarkable pages. > > > > as far as events, etc, you would have to visit all cached things in > > cache and do whatever it is you need to do. wicket cant help you here > > because the cache implementation is purely your own. > > > > -igor > > > > On Thu, Nov 13, 2008 at 8:28 AM, Tremelune <[EMAIL PROTECTED]> > wrote: > >> > >> We have many components that require heavy operations to gather the > necessary > >> data, and I was wondering if there was a way to cache the Wicket objects > >> that have pulled the data. > >> > >> I have seen similar questions come up before, and the common answer was > to > >> simply cache the data being pulled, and not the Wicket objects. Because > we > >> have components pulling data from different places in different ways, > this > >> would be like putting a padlock on my TV and guitar instead of locking > the > >> door to my apartment. It also means that, if I got a new stereo, I'd > have to > >> remember to handle that new case as well, instead of it being handled by > the > >> door lock automagically. My last example in this unusual metaphor would > be > >> my iPod: It's too cheap to explicitly handle, but it's nice to have the > lock > >> on the front door take care of it anyway. > >> > >> My particular app would benefit from a per-user cache based on the way > data > >> is pulled. Pages are different for each user, but once they view the > page, > >> data rarely changes. I imagine this would be as easy as stuffing > something > >> in the Wicket session. It would stagnate with the HTTP session > naturally. > >> > >> My app would also need a few hooks or event listeners to trigger a > clear. > >> For instance, if a user deletes a Horse from his Barn, I would want the > >> BarnPanel to know it needs to refresh on the next rendering. > >> > >> Is there anything like this that exists in Wicket? Or pieces I could use > to > >> build it? I think it would be very handy. > >> -- > >> View this message in context: > http://www.nabble.com/Per-user%2C-event-aware-page-component-caching-tp20481886p20481886.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] > >
