Got my vote. I'm all for keeping things focused and simple. It'd be a pity if Hivemind bloated up much more.
-----Original Message----- From: James Carman [mailto:[EMAIL PROTECTED] I understand the importance of localization and I agree that it is often overlooked. My point is that localization isn't a key feature for a dependency injection container and shouldn't be woven into the core framework. I would recommend that we come up with a highly configurable and easy to use localization framework (or service) and include it with HiveMind in the hivemind-lib. -----Original Message----- From: Howard Lewis Ship [mailto:[EMAIL PROTECTED] Localization is one of the most important, and under-implemented, aspects of web applications. Tapestry has always had excellent support for localization, and as Tapestry 3.1 is refactored around HiveMind 1.1, I want to ensure that we can continue to support localization. The key issue is that each request (in each thread) will be for a different user and potentially in a different locale. The emphasis in 3.1 and beyond is to move application logic into HiveMInd ... but we still want to be able to produce error (and other) messages in the user's preferred locale. HiveMind's mandate, to be contained within a single JVM, gives us the tool (threaded server model) to track the user's domain through the presentation layer (Tapestry) and into the application layer (HiveMind services) ... something that is awkward to accomplish in the nomral EJB-style layering (without considerable forethought). On Tue, 25 Jan 2005 11:29:44 -0500, James Carman <[EMAIL PROTECTED]> wrote: > I'm all for completely removing the Locale stuff from the registry > altogether. So, you know I'd be for this, since it's a step in that > direction. I just don't understand why we need to muddy up a dependency > injection (or IoC) container with localization stuff. > > -----Original Message----- > From: Howard Lewis Ship [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 25, 2005 9:02 AM > To: [email protected] > Subject: [SPAM] Removing %key contribution syntax > > I'd like to take a crack at allowing the locale to be changed > dynamically. This would be more in keeping with HiveMind + a web > application (i.e., Tapestry), where each thread/request may want > messages localized to a different locale. > > I pretty much know how this will work: > - Registry's locale is the *default* locale > - A LocaleHolder service that stores the locale for the current thread > - A MessagesProxy > > MessagesProxy: The proxy is what's injected into services. It's > implementation will get the Locale from the LocaleHolder and ask the > Module for the concrete Messages for that locale, and redirect > implementations to that concrete Messages instance. > > The only problem is the %key syntax in the descriptors. That will > only be evaluated ONCE and in some arbitrary locale. I would propose > that the syntax be removed (or, at the very least, deprecated). > Thoughts? > > -- > Howard M. Lewis Ship > Independent J2EE / Open-Source Java Consultant > Creator, Jakarta Tapestry > Creator, Jakarta HiveMind > > Professional Tapestry training, mentoring, support > and project work. http://howardlewisship.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator, Jakarta Tapestry Creator, Jakarta HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com -- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator, Jakarta Tapestry Creator, Jakarta HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For a^Q0�ional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
