Joe, 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. Paul Joe Germuska <[EMAIL PROTECTED]> 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 -- 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] --------------------------------- Yahoo! Music Unlimited - Access over 1 million songs.Try it free.
