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