You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Igor Drobiazko <ig...@gmail.com> on 2010/11/04 00:20:24 UTC
Cache keys for page-based objects
Hi there,
Tapestry tries to cache a lot of objects like page and component instances,
template object, which are expensive to build. Currently the cache keys
consist of a page/component name + locale or class name + locale.
I have a very important use case to create some custom keys that allow me to
store more instances into the cache. For example I need not only
locale-specific instances (like MyPage-en, MyPage-de), but also
device-specific or customer-specific page instances (like MyPage-iphone-en,
MyPage-iphone-de, MyPage-de) .
So, I would like to add a new public service in 5.3 (e.g. CacheKeyProvider
or similar) which will be used by PageSource, PageLoader,
ComponentTemplateSource to create cache keys that are not limited to locale.
Any thoughts? Any objections? Any feedback is appreciated as these feature
is very important for me. Right now I would work on the internal API, but I
want to make sure the will be public API for it in the future.
--
Best regards,
Igor Drobiazko
http://tapestry5.de
Re: Cache keys for page-based objects
Posted by jugglingcats <na...@akirkpatrick.com>.
Hi, I agree with you Howard that this is closely related to the requirement
to load templates from a db, which is still an interesting concept for
heavily CMS driven sites.
Is it too much to ask that, at least for pages, the template locator logic
could be delegated to the page class itself?!
For example, take a Product page with url /product/12345, and then the
requirement to override this page specifically for product 12345 but not
others. Then the page class could look something like:
@PageActivationContext
private long productId
public Resource getTemplate() {
return cmsResourceLocator.find(productId);
}
Maybe this starts to look a little MVC-like though.
Regards, Alfie.
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Cache-keys-for-page-based-objects-tp3249337p3274735.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Cache keys for page-based objects
Posted by Igor Drobiazko <ig...@gmail.com>.
It looks good except the name. Maybe "ComponentSelector" is better as you
need to search for components as well.
I guess there is no need to have more than two dimension for messages.
On Thu, Nov 4, 2010 at 6:00 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
> I can definitely see 4 dimensions as useful: page name, locale, device,
> skin.
>
> It seems to me that the you do need a object that encapsulates:
> 1) the key used to uniquely identify the page (with the given page name,
> locale, 3rd, 4th).
> 2) The algorithm used to locate resources appropriate to the key
>
> I think "Dimensions" is not the right name for this, but "Selector" may be
> part of it.
>
> I think this change to API should also encapsulate (or at least, not rule
> out later) the task of allowing templates to live outside the web context
> or
> class path, i.e., from a database or other external source (which brings
> with it the challenge of dealing with invalidations of that external data).
>
> public interface PageSelector
> {
> Object getCacheKey();
>
> Resource findSelectedResource(....);
> }
>
> So where the page name and locale is passed around today, we'll want to
> pass
> around the PageSelector and, as we identify resources (such as properties
> files or template files), the findSelectedResource() method can be used.
>
> Message catalogs are tricky, because we search for multiple versions AND
> there's a hierarchy. Do other dimensions, besides locale, play a part
> here?
> Can we inject other dimensions, as we do the Locale?
>
> It can be a big can of worms!
> On Thu, Nov 4, 2010 at 9:50 AM, Igor Drobiazko <igor.drobiazko@gmail.com
> >wrote:
>
> > Right now I have a custom implementation of ComponentTemplateLocator
> > service
> > which is responsible to locate the template from a subfolder. The name of
> > the subfolder is the name of the dimension.
> >
> > I guess what is needed is a "DimensionsProvider" which defaults to two
> > dimensions. This service is then used for caching and template locating.
> If
> > needed, app developers may provide their own implementation of the
> service
> > to add more dimensions.
> >
> > Maybe the unlimited number of dimension is kind of over-engineering.
> > Probably it is sufficient to habe 3 or 4 dimension, as you sugessted.
> What
> > do you think?
> >
> > On Thu, Nov 4, 2010 at 1:42 AM, Howard Lewis Ship <hl...@gmail.com>
> > wrote:
> >
> > > Seems like there's some other work down the line ... for example, if
> you
> > > hook in a "device" dimension into the cache (*) then how does that new
> > > dimension travel down to the code that identifies the correct template?
> > >
> > > I think this is a good idea but it's something that should be Done
> Right.
> > >
> > > I also can't help but wonder if this doesn't overlap with the frequent
> > > request to get templates from the database ... which itself introduces
> > the
> > > challenge of determining when a database-originated template has
> changed.
> > >
> > > (*) The current dimensions are page name and request locale. It seems
> > > reasonable to add a 3rd or perhaps 4th dimension.
> > >
> > > On Wed, Nov 3, 2010 at 4:20 PM, Igor Drobiazko <
> igor.drobiazko@gmail.com
> > > >wrote:
> > >
> > > > Hi there,
> > > >
> > > > Tapestry tries to cache a lot of objects like page and component
> > > instances,
> > > > template object, which are expensive to build. Currently the cache
> keys
> > > > consist of a page/component name + locale or class name + locale.
> > > >
> > > > I have a very important use case to create some custom keys that
> allow
> > me
> > > > to
> > > > store more instances into the cache. For example I need not only
> > > > locale-specific instances (like MyPage-en, MyPage-de), but also
> > > > device-specific or customer-specific page instances (like
> > > MyPage-iphone-en,
> > > > MyPage-iphone-de, MyPage-de) .
> > > >
> > > > So, I would like to add a new public service in 5.3 (e.g.
> > > CacheKeyProvider
> > > > or similar) which will be used by PageSource, PageLoader,
> > > > ComponentTemplateSource to create cache keys that are not limited to
> > > > locale.
> > > >
> > > >
> > > > Any thoughts? Any objections? Any feedback is appreciated as these
> > > feature
> > > > is very important for me. Right now I would work on the internal API,
> > but
> > > I
> > > > want to make sure the will be public API for it in the future.
> > > >
> > > > --
> > > > Best regards,
> > > >
> > > > Igor Drobiazko
> > > > http://tapestry5.de
> > > >
> > >
> > >
> > >
> > > --
> > > Howard M. Lewis Ship
> > >
> > > Creator of Apache Tapestry
> > >
> > > The source for Tapestry training, mentoring and support. Contact me to
> > > learn
> > > how I can get you up and productive in Tapestry fast!
> > >
> > > (971) 678-5210
> > > http://howardlewisship.com
> > >
> >
> >
> >
> > --
> > Best regards,
> >
> > Igor Drobiazko
> > http://tapestry5.de
> >
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
>
> The source for Tapestry training, mentoring and support. Contact me to
> learn
> how I can get you up and productive in Tapestry fast!
>
> (971) 678-5210
> http://howardlewisship.com
>
--
Best regards,
Igor Drobiazko
http://tapestry5.de
Re: Cache keys for page-based objects
Posted by Howard Lewis Ship <hl...@gmail.com>.
I can definitely see 4 dimensions as useful: page name, locale, device,
skin.
It seems to me that the you do need a object that encapsulates:
1) the key used to uniquely identify the page (with the given page name,
locale, 3rd, 4th).
2) The algorithm used to locate resources appropriate to the key
I think "Dimensions" is not the right name for this, but "Selector" may be
part of it.
I think this change to API should also encapsulate (or at least, not rule
out later) the task of allowing templates to live outside the web context or
class path, i.e., from a database or other external source (which brings
with it the challenge of dealing with invalidations of that external data).
public interface PageSelector
{
Object getCacheKey();
Resource findSelectedResource(....);
}
So where the page name and locale is passed around today, we'll want to pass
around the PageSelector and, as we identify resources (such as properties
files or template files), the findSelectedResource() method can be used.
Message catalogs are tricky, because we search for multiple versions AND
there's a hierarchy. Do other dimensions, besides locale, play a part here?
Can we inject other dimensions, as we do the Locale?
It can be a big can of worms!
On Thu, Nov 4, 2010 at 9:50 AM, Igor Drobiazko <ig...@gmail.com>wrote:
> Right now I have a custom implementation of ComponentTemplateLocator
> service
> which is responsible to locate the template from a subfolder. The name of
> the subfolder is the name of the dimension.
>
> I guess what is needed is a "DimensionsProvider" which defaults to two
> dimensions. This service is then used for caching and template locating. If
> needed, app developers may provide their own implementation of the service
> to add more dimensions.
>
> Maybe the unlimited number of dimension is kind of over-engineering.
> Probably it is sufficient to habe 3 or 4 dimension, as you sugessted. What
> do you think?
>
> On Thu, Nov 4, 2010 at 1:42 AM, Howard Lewis Ship <hl...@gmail.com>
> wrote:
>
> > Seems like there's some other work down the line ... for example, if you
> > hook in a "device" dimension into the cache (*) then how does that new
> > dimension travel down to the code that identifies the correct template?
> >
> > I think this is a good idea but it's something that should be Done Right.
> >
> > I also can't help but wonder if this doesn't overlap with the frequent
> > request to get templates from the database ... which itself introduces
> the
> > challenge of determining when a database-originated template has changed.
> >
> > (*) The current dimensions are page name and request locale. It seems
> > reasonable to add a 3rd or perhaps 4th dimension.
> >
> > On Wed, Nov 3, 2010 at 4:20 PM, Igor Drobiazko <igor.drobiazko@gmail.com
> > >wrote:
> >
> > > Hi there,
> > >
> > > Tapestry tries to cache a lot of objects like page and component
> > instances,
> > > template object, which are expensive to build. Currently the cache keys
> > > consist of a page/component name + locale or class name + locale.
> > >
> > > I have a very important use case to create some custom keys that allow
> me
> > > to
> > > store more instances into the cache. For example I need not only
> > > locale-specific instances (like MyPage-en, MyPage-de), but also
> > > device-specific or customer-specific page instances (like
> > MyPage-iphone-en,
> > > MyPage-iphone-de, MyPage-de) .
> > >
> > > So, I would like to add a new public service in 5.3 (e.g.
> > CacheKeyProvider
> > > or similar) which will be used by PageSource, PageLoader,
> > > ComponentTemplateSource to create cache keys that are not limited to
> > > locale.
> > >
> > >
> > > Any thoughts? Any objections? Any feedback is appreciated as these
> > feature
> > > is very important for me. Right now I would work on the internal API,
> but
> > I
> > > want to make sure the will be public API for it in the future.
> > >
> > > --
> > > Best regards,
> > >
> > > Igor Drobiazko
> > > http://tapestry5.de
> > >
> >
> >
> >
> > --
> > Howard M. Lewis Ship
> >
> > Creator of Apache Tapestry
> >
> > The source for Tapestry training, mentoring and support. Contact me to
> > learn
> > how I can get you up and productive in Tapestry fast!
> >
> > (971) 678-5210
> > http://howardlewisship.com
> >
>
>
>
> --
> Best regards,
>
> Igor Drobiazko
> http://tapestry5.de
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to learn
how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
Re: Cache keys for page-based objects
Posted by françois facon <fr...@gmail.com>.
Hi
In Tapestry 5.1.0.5, we use the variant code from a modified locale to add
more information about the targeted template.
For WebMobile solution, this is used to add information about device.
Template can be customized for a specific device family.
This could be use provide a html5 template for iPhone for example.
For Templating solution, this is used to select a template according to
values from the activation context parameters.
There is a need for 4 or 5 dimensions to identify a template according to
activation context parameters(3th dim) for a specific user(4 th dim) and for
specific device (5th dim)
2010/11/4 Thiago H. de Paula Figueiredo <th...@gmail.com>
> On Thu, 04 Nov 2010 14:50:55 -0200, Igor Drobiazko <
> igor.drobiazko@gmail.com> wrote:
>
> Maybe the unlimited number of dimension is kind of over-engineering.
>>
>
> Most of the time, having more than one dimension is as complex as having an
> unlimited number. Isn't that true? :)
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
> and instructor
> Owner, Ars Machina Tecnologia da Informação Ltda.
> http://www.arsmachina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
Re: Cache keys for page-based objects
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Thu, 04 Nov 2010 14:50:55 -0200, Igor Drobiazko
<ig...@gmail.com> wrote:
> Maybe the unlimited number of dimension is kind of over-engineering.
Most of the time, having more than one dimension is as complex as having
an unlimited number. Isn't that true? :)
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Cache keys for page-based objects
Posted by Igor Drobiazko <ig...@gmail.com>.
Right now I have a custom implementation of ComponentTemplateLocator service
which is responsible to locate the template from a subfolder. The name of
the subfolder is the name of the dimension.
I guess what is needed is a "DimensionsProvider" which defaults to two
dimensions. This service is then used for caching and template locating. If
needed, app developers may provide their own implementation of the service
to add more dimensions.
Maybe the unlimited number of dimension is kind of over-engineering.
Probably it is sufficient to habe 3 or 4 dimension, as you sugessted. What
do you think?
On Thu, Nov 4, 2010 at 1:42 AM, Howard Lewis Ship <hl...@gmail.com> wrote:
> Seems like there's some other work down the line ... for example, if you
> hook in a "device" dimension into the cache (*) then how does that new
> dimension travel down to the code that identifies the correct template?
>
> I think this is a good idea but it's something that should be Done Right.
>
> I also can't help but wonder if this doesn't overlap with the frequent
> request to get templates from the database ... which itself introduces the
> challenge of determining when a database-originated template has changed.
>
> (*) The current dimensions are page name and request locale. It seems
> reasonable to add a 3rd or perhaps 4th dimension.
>
> On Wed, Nov 3, 2010 at 4:20 PM, Igor Drobiazko <igor.drobiazko@gmail.com
> >wrote:
>
> > Hi there,
> >
> > Tapestry tries to cache a lot of objects like page and component
> instances,
> > template object, which are expensive to build. Currently the cache keys
> > consist of a page/component name + locale or class name + locale.
> >
> > I have a very important use case to create some custom keys that allow me
> > to
> > store more instances into the cache. For example I need not only
> > locale-specific instances (like MyPage-en, MyPage-de), but also
> > device-specific or customer-specific page instances (like
> MyPage-iphone-en,
> > MyPage-iphone-de, MyPage-de) .
> >
> > So, I would like to add a new public service in 5.3 (e.g.
> CacheKeyProvider
> > or similar) which will be used by PageSource, PageLoader,
> > ComponentTemplateSource to create cache keys that are not limited to
> > locale.
> >
> >
> > Any thoughts? Any objections? Any feedback is appreciated as these
> feature
> > is very important for me. Right now I would work on the internal API, but
> I
> > want to make sure the will be public API for it in the future.
> >
> > --
> > Best regards,
> >
> > Igor Drobiazko
> > http://tapestry5.de
> >
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
>
> The source for Tapestry training, mentoring and support. Contact me to
> learn
> how I can get you up and productive in Tapestry fast!
>
> (971) 678-5210
> http://howardlewisship.com
>
--
Best regards,
Igor Drobiazko
http://tapestry5.de
Re: Cache keys for page-based objects
Posted by Howard Lewis Ship <hl...@gmail.com>.
Seems like there's some other work down the line ... for example, if you
hook in a "device" dimension into the cache (*) then how does that new
dimension travel down to the code that identifies the correct template?
I think this is a good idea but it's something that should be Done Right.
I also can't help but wonder if this doesn't overlap with the frequent
request to get templates from the database ... which itself introduces the
challenge of determining when a database-originated template has changed.
(*) The current dimensions are page name and request locale. It seems
reasonable to add a 3rd or perhaps 4th dimension.
On Wed, Nov 3, 2010 at 4:20 PM, Igor Drobiazko <ig...@gmail.com>wrote:
> Hi there,
>
> Tapestry tries to cache a lot of objects like page and component instances,
> template object, which are expensive to build. Currently the cache keys
> consist of a page/component name + locale or class name + locale.
>
> I have a very important use case to create some custom keys that allow me
> to
> store more instances into the cache. For example I need not only
> locale-specific instances (like MyPage-en, MyPage-de), but also
> device-specific or customer-specific page instances (like MyPage-iphone-en,
> MyPage-iphone-de, MyPage-de) .
>
> So, I would like to add a new public service in 5.3 (e.g. CacheKeyProvider
> or similar) which will be used by PageSource, PageLoader,
> ComponentTemplateSource to create cache keys that are not limited to
> locale.
>
>
> Any thoughts? Any objections? Any feedback is appreciated as these feature
> is very important for me. Right now I would work on the internal API, but I
> want to make sure the will be public API for it in the future.
>
> --
> Best regards,
>
> Igor Drobiazko
> http://tapestry5.de
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to learn
how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com