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 <[email protected]> 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 <[email protected] > >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
