Andreas,
I agree that this is a very interesting finding and a useful scenario.
Nevertheless, I see two downsides of changing the default interceptor
order as you suggested:
1) (minor) the request_locale parameter will not be removed from the
request before params are applied, which might lead to some confusion
regarding log output
2) (major) the type conversion for locale dependent parameters such as
date and numbers will not regard the set locale. This would be a very
inconsistent behaviour, because the user would surely expect to have the
locale be applied to the conversion
- Rene
Andreas Joseph Krogh schrieb:
On Tuesday 05 May 2009 02:33:14 pm Wes Wannemacher wrote:
Unless anyone has anything they want to commit first...
I'll give it a couple of hours while I read the docs on releasing.
I don't want to hold the release, but I noticed this:
Enabling this in struts.xml makes it possible to have "named-variable"
wildcard-mappings for namespaces:
<bean type="com.opensymphony.xwork2.util.PatternMatcher"
name="namedVariablePatternMatcher"
class="com.opensymphony.xwork2.util.NamedVariablePatternMatcher"/>
<constant name="struts.patternMatcher"
value="namedVariablePatternMatcher"/>
You can have namespaces like:
<package name="mypackage" extends="struts-default"
namespace="/myns/{request_locale}">
And it will set the request-locale using the i18n-interceptor to whatever is
set in {request_locale}. You have to place the i18n-interceptor *after* the
params-interceptor, which requires overriding the default interceptor-stack.
This is very cool and makes it possible to easily switch locale without having to code
for it and keeping your struts2-config consistent. It could, however, benefit from better
documentation, it's pretty hard finding out that this is possible asking Mr. Google.
Maybe mentioning it in the "wildcard mapping"-section would be a good place?
--
René Gielen
IT-Neering.net
Saarstrasse 100, 52062 Aachen, Germany
Tel: +49-(0)241-4010770
Fax: +49-(0)241-4010771
http://twitter.com/rgielen
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
