Joe Germuska <[EMAIL PROTECTED]> wrote:That said, I don't think you should not
do the work you describe,
just because you may have to leave the Localizer (or whatever you
call it) in the ServletContext under a well known key. It's just
that it feels so outdated!
Here's my solution. Unless anyone feels strongly about it, I am going to open
up a ticket and submit my patch.
1) I am going to retain the Globals.LOCAL_KEY as the constant for
session-strategy localization. Previous applications will continue using this
without a problem.
2) I am going to add a LOCAL_RESOLVER_KEY constant which returns an object that
implements these methods:
Locale resolveLocale(HttpServletRequest request);
void setLocale(HttpServletRequest request, HttpServletResponse response, Locale
locale);
These methods will not be of any interface. The resolver object can be any
class which implements those two methods, and I will use BeanUtils to retrieve
them. The reason I am choosing this design over an interface is because I want
to plug in implementations from any framework (like Struts2 or Spring) without
requiring an adapter interface. At most, the adapter interface would be just a
pass-through and so it has questionable value.
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).
4) Modify Action.get/setLocale to delegate to the locale strategy. The
retrieval of the strategy will most likely be in RequestUtils.
If this works right, I should be able to punch to bridge Struts 1, Struts 2,
and Spring all behind the scenes. For those developing Struts 2, do you have
any class which comes close to the above? I'd like to coordinate with you so
that Struts1-Struts2 apps can bridge localization in the 2.0.0 release.
I am targetting 1.3.6+
Paul
---------------------------------
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+
countries) for 2ยข/min or less.
