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
