[s1] New Locale Resolution (STR-2897)

[Paul Benedict <pb...@apache.org>]

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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org