On Mar 27, 2006, at 5:54 AM, Antonio Petrelli wrote:

I've noticed that both DefinitionsFactory and ComponentDefinitions are both too (IMHO) tightly bound to the Locale. What I mean is that maybe using Locale class to distinguish between different sets of definitions is not a good idea. From my point of view, I think that where you are using Locale maybe it should be used a simple Object. This way you leave to the implementation what's the use of that "Locale" In the Struts-Tiles version there is the concept of "key" in the FactorySet.createDefinitionsFactory, that is a simple Object. I use it to do my own way to localize definitions. In other words, don't you think that "Locale" in those interfaces should be Objects?

Ok, I had to take a day to think about this :-) I see your point, but I also agree with Craig that Locale is important. Here's the way I see it: We see the tiles definitions set as a 2-dimensional data set. One axis is the name and the other is the locale. There's the added wrinkle that definition data from one name can inherit data from another name. By adding "channel" to the mix I think you are adding a 3rd dimension. In your Dimensions architecture do you choose a definition based on name, channel, *and* locale or only name and channel?

So, I don't think we want to lose the dependency on Locale. (I'll have to take some more time to consider your point about it being a final class.) I think Locale is a critical differentiation in choosing a Tiles definition. But what about adding an API that requires a generic Object key parameter to support the 3rd dimension? I'm not sure if the use case is common enough to make it part of the core API. If not, could it be added to an extension? Again, I can see where you are coming from, but I really don't think we should lose the locale dimension that's already there.

Thoughts?
Greg


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to