And if you are using spring it's really easy to inject caching using the
spring module cache sub project, when using your approach.
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 <[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]
--
-Wicket for love
Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
