I pictured this as as:
public interface ThreadLocaleHolder
{
public Locale getThreadLocale();
public void setThreadLocale(Locale locale);
}
public interface MessagesSource
{
public Messages getMessagesForModule(Module module);
}
public interface MessagesFactory
{
public Messages constructMessages(Module module, Locale locale);
}
There woudl be two impls of Messages here.
The MessagesProxy would ask the ThreadLocaleHolder for the current locale.
It would maintain a map of MessagesImpl keyed on Locale. If it doesn't have one,
it will ask the MessagesFactory for it.
Making this work will require a couple of specialized
ServiceImplementationFactories, since a service normally doesn't have
access to the Module.
In addition, the BuilderFactory will need a SIF so that it can access
the MessagesSource.
MessagesSource will have to use <create-instance>, not <invoke-factory>.
On Sat, 11 Sep 2004 09:16:56 -0400, James Carman
<[EMAIL PROTECTED]> wrote:
> I like the idea of a ThreadLocal, or the equivalent via a Threaded/Pooled
> service which holds the "currentLocale." Maybe we could make Messages a
> full-fledged service and allow something like HiveMindFilter to set the
> "currentLocale" on it...
>
> public interface Messages
> {
> public void setCurrentLocale( Locale locale );
> }
>
> When it goes back into the pool (if it's pooled), it would revert back to
> the default locale. The messages implementation should change the way it
> looks up messages, by using the "currentLocale." I think Messages already
> only loads messages from the current module, correct? Doesn't that address
> what we need? It's early and I haven't had my first cup of coffee yet, so I
> might be missing something.
>
>
>
>
> -----Original Message-----
> From: Howard Lewis Ship [mailto:[EMAIL PROTECTED]
> Sent: Saturday, September 11, 2004 8:42 AM
> To: [email protected]
> Subject: Re: Use of a Locale...
>
> I can see stripping out %key. Likewise, the resource translator does
> a localized lookup, and that could be removed (it's easy enough to do
> using the Resource API).
>
> I still like the idea of being able to inject a Messages instance into
> a service and have it "do the right thing" w.r.t. Locale ... but
> Locale would be thread local. Can we pursue that?
>
> I think that Locale may no longer be needed by RegistryBuilder ... or,
> of it is, it's merely a default locale that isn't necessarily used
> when constructing the Registry.
>
> On Fri, 10 Sep 2004 18:59:18 -0400, James Carman
> <[EMAIL PROTECTED]> wrote:
> > Well, how often do you really need to actually store the localized
> messages
> > within your implementation code? I wouldn't think that folks would use
> > localized message values for configuration data (db usernames, etc.). I
> > guess you could use that sort of information to make a service act more
> > "snooty" if it's in a French locale. ;-)
> >
> > Even the HiveMind framework itself uses the MessageFormatter class to
> > dynamically lookup message values rather than storing their values. I
> would
> > vote +1 (soon to be binding) to remove the %key mechanism. I never could
> > come up with a good use for it, myself. I think we could come up with a
> > more robust i18n service implementation outside of the core framework (in
> > either lib or a "contrib" package).
> >
> > One problem with creating an i18n implementation is that you wouldn't want
> > modules to step on the localization keys of each other (two modules define
> a
> > message with the "errorMessage" key for example). That brought up an
> idea!
> > How about a new "module" service model? Each module would have its own
> > instance of the implementation object. And, for those services which need
> > to ONLY load resources from their own module (a sort of swim lane, if you
> > will), we could provide them with a ResourceLoader (or whatever you want
> to
> > call it) which does just that. It's just a thought (or 2 or 3).
> >
> >
> >
> >
> > -----Original Message-----
> > From: Howard Lewis Ship [mailto:[EMAIL PROTECTED]
> > Sent: Friday, September 10, 2004 10:21 AM
> > To: [email protected]
> > Subject: Re: Use of a Locale...
> >
> > Messages are loaded just-in-time, using the Registry's locale.
> >
> > For me, the issue is that the Locale is fixed which works fine (I
> > guess) for a standalone program, but becomes problematic for web apps
> > (Tapestry apps) where different concurrent users need messages in
> > different locales.
> >
> > I suppose we could implement a kind of thread-local to store the
> > user's locale. This would be used when accessing localized messages
> > from code (i.e., via a Messages object).
> >
> > The problem is the %key mechanism in contributions, which is another
> > way to allow access to localized messages. These become strings, or
> > parts of strings, that then can "flow" (via contributions, schemas,
> > collaborating services, etc.) into all kinds of unpredictable places.
> > So what locale is used for them ... and how do they get properly
> > localized? I don't have a solution.
> >
> > To some degree, what's needed iis a way to keep messages virtual (keys
> > + parameters) right up until there's a known locale, then fold them
> > down to localized strings. I can see this as a service on top of
> > HiveMind. I'd like one solution that covers everything, magically,
> > but I don't seem to have it!
> >
> > On Fri, 10 Sep 2004 16:09:01 +0200, Mika�l Cluseau <[EMAIL PROTECTED]>
> > wrote:
> > >
> > >
> > > James Carman wrote:
> > > > The locale-specific registry building has always had a bad smell to
> me.
> > > > I just don't know if it belongs in a "microkernel" like HiveMind.
> Sure,
> > > > we should provide a service that allows access to internationalized
> > > > messages, but that doesn't have to be part of the core framework.
> Maybe
> > > > I'm not seeing the benefits. Am I missing something?
> > > >
> > >
> > > I thought it was for module messages (i.e. to localize logs). Indeed,
> > > they need to be loaded by HiveMind just-in-time, depending on the
> > > system's default locale.
> > >
> > > I may miss something too ;-)
> > >
> > > --
> > > Mika�l
> > >
> > > ---------------------------------------------------------------------
> > > 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
> > 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
> 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
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
