You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Tremelune <tr...@ensaster.com> on 2008/11/13 17:28:19 UTC
Per-user, event-aware page/component caching
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Per-user, event-aware page/component caching
Posted by Jeremy Thomerson <je...@wickettraining.com>.
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 <ig...@gmail.com>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 <ig...@gmail.com>
> 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 <tr...@ensaster.com>
> 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: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Per-user, event-aware page/component caching
Posted by Nino Saturnino Martinez Vazquez Wael <ni...@jayway.dk>.
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 <ig...@gmail.com> 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 <tr...@ensaster.com> 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: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
-Wicket for love
Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Per-user, event-aware page/component caching
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <ig...@gmail.com> 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 <tr...@ensaster.com> 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: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Per-user, event-aware page/component caching
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <tr...@ensaster.com> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org