I have the majority of the new code ready for Struts 1 which enables
more flexible and powerful locale resolution. This enhancement is
currently being tracked under:
https://issues.apache.org/struts/browse/STR-2897
90% of the new code has been poached from the Spring Framework (they do
a very fine job over there). It's identical to what I wanted to add to
Struts anyway, and since they release their code under ASF2 license,
there's no IP problem.
I have introduced these new packages and classes:
org.apache.struts.locale
* ActionLocaleContext - interface to get locale
* ActionLocaleContextHolder - thread locale holder of the above
* SimpleActionLocaleContextHolder - default implementation
org.apache.struts.locale.resolver
* AbstractActionLocaleResolver - base class for resolvers
* AcceptHeaderActionLocaleResolver - resolved locale by HTTP header
* ActionLocaleResolver - resolver interface
* CookieActionLocaleResolver - cookie resolution strategy
* FixedActionLocaleResolver - fixed locale strategy
* SessionActionLocaleResolver - like Struts is now
org.apache.struts.util
* LocaleUtils - utility methods for selecting locale
org.apache.struts.action
* Action - getLocale/setLocale uses LocaleUtils underneath
The request processor has a new attribute which allows the default
ActionLocaleResolver class to be configured. If the controller is
configured to select the locale, the resolver will be used, and the
default implementation is SessionActionLocaleResolver.
<controller>
<set-property property="localeResolverClass"
value="...CookieActionLocaleResolver" />
</controller>
The controller also places the resolver in the request as an attribute,
which is where the resolver is always retrieved by utility classes. This
allows any subclass of the processor or chain or action to replace the
resolver during the request for whatever purposes. The tag library is
also retrofitted to use the resolution strategies.
The big win here is that now people can run I18N sites with Struts
without having to instantiate the session. I like to put the user's
selected locale in cookies, and that's what I am doing now (locally)
with this enhancement, and turn session creation off until it's needed.
Also the fallback strategy to get the locale, if the resolver doesn't
return anything, includes searching JSTL's locale too.
Lastly, the code is pretty modular. 95% of it could be plugged into S2
without modification. So with a big change like this, what should be
done before checking in? Just check it in or what?
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
