Craig McClanahan ha scritto:
One of the reasons I think using a Locale is a good choice is that you'll need one later on anyway ... to generate Locale-sensitive date formats, for example.
You're right. But the big problem is that Locale is a final class. I think that an "extensible" locale class could be useful. Using Locale class you're bound to that class. You can internationalize your Tiles definitions, that's true (for each locale you have different Tiles definition) but then you cannot separate definition, for example, by client device. It IS possible with Struts-Tiles (again through the use of FactorySet), because the "key" is an Object. The class I18NFactorySet extends FactorySet, take your conclusions...
It is also the mechanism used universally throughout Java for this kind of decision.
I think Tiles definitions are not only a question of I18N...
Finally, Struts already keeps track of the current Locale for a user in a session variable, so it's easy to grab when you need it.
But instead of using Locale class, why Object can't be used? Is a class cast too costly?
(JSF and other frameworks do the same sort of thing too.)
Sorry but Tiles won't be Struts-Tiles anymore ;-) Ciao Antonio --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
