What you could actually do, is implement a Component Pool.
Take a look at the Commons-Pool project and then, role your own pool. :-)
Combine a pool with an application or a session and good luck!
Apache Commons Pool Project
http://commons.apache.org/pool/
Regards,
Bruno
On Nov 13, 2008 5:43pm, Jeremy Thomerson <[EMAIL PROTECTED]> wrote:
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 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
> 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
> 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]
>
>
