struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Benedict <>
Subject Re: Locale resolver (Re: WW/SAF2 i18n & Cintoo Messages)
Date Fri, 30 Jun 2006 20:01:38 GMT

First, thanks for pointing out cintoo. I looked at the source and it seems like it could be
something s1/2 could share together. Are you interested in investigating this with me? Is
anyone else?

Second, placing the logic in a SetLocale command is fine, but it would be nothing more than
delegate to the real class which does the work. The getting/setting of the locale should be
an independent class so that other implementations and adjunct frameworks and use it too.
For instance, I ocassionaly consult with the user's Struts locale, if it exists, in non-struts
tag libraries so that my code is not totally ignorant of frameworks. This is only possible
because the retrieving of the locale is in a independent class: RequestUtils.

But I think the design should be more fine grained, so that getting and setting of the locale
exist in a class specific to locale methods. For Struts 1, I am recommending a pluggable locale
resolver like Spring to get/set the strategy if needed. The RP Chain of course *should* use
the strategy to set the locale directly, but the strategy should never be totally hidden so
those outside the chain cannot access it either.


Joe Germuska <> wrote: At 11:36 AM -0700 6/30/06, Paul Benedict wrote:
>Some further reflections:
>WW and SPR both use ThreadLocal to store the locale of the thread's 
>request. However, there still needs to be a shared object that can 
>set/retrieve the local across web frameworks.
>So I 100% agree with the ThreadLocal use, but it is not directly 
>relevant to my question. That would be an implementation of the 
>locale resolver, in which it would expose the locale in the thread 
>for a particular framework.

On the other hand, perhaps using a thread local is a more elegant 
strategy than requiring a specific mechanism which looks for a 
specific object in the ApplicationContext and uses a specific 
reflection mechanism to find a locale.

At 10:53 AM -0700 6/30/06, Paul Benedict wrote:
>3) Modify RequestUtils.getUserLocale to lookup the stategy first and 
>use it. RequestUtils will have a pre-built strategy for doing 
>session look-up, to implement requirement #1 (see above).

That is, there are lots of ways to make sure that Globals.LOCALE_KEY 
points to the right locale, and you could leave the details which you 
specify (to do with Globals.LOCALE_RESOLVER_KEY) more up to the 
implementor.  I might just write a ServletFilter instead of putting 
in a LOCALE_RESOLVER, or I might write a custom chain command.  It 
seems to me better to leave the things which need the Locale ignorant 
of how to find it.  In fact, you could easily replace the "SetLocale" 
command with another that consulted cookies or request parameters.

Joe Germuska *    

"You really can't burn anything out by trying something new, and
even if you can burn it out, it can be fixed.  Try something new."
 -- Robert Moog

To unsubscribe, e-mail:
For additional commands, e-mail:

Yahoo! Music Unlimited - Access over 1 million songs.Try it free. 
  • Unnamed multipart/alternative (inline, 8-Bit, 0 bytes)
View raw message