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
--
Joe Germuska
[EMAIL PROTECTED] * http://blog.germuska.com
"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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
