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]
