On 6/30/06, Paul Benedict <[EMAIL PROTECTED]> wrote:
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 had a quick peek at Cintoo messages today (Apache 2 license) -
initial impression was its a nice implementation for i18n. They use
ThreadLocale to store the Locale which makes it available everywhere.
I believe that approach has been used by the ww guys and from memory I
think there are similar concepts for configuring resources
(packaging). It would interesting to hear one of the WW guys if they
had time to look at it. Perhaps we can use it to do the job Commons
Resources was intended for.
Anyway I digress, this would be one way of making Locale available all
over the place (messages, validation, tiles) without necessarily
changing the API.
http://messages.cintoo.org/
http://www.theserverside.com/news/thread.tss?thread_id=41116
http://www.infoq.com/news/Cintoo-Messages-1.0-i18n
Niall
P.S. don't look at the cintoo site using IE - its a mess - OK in firefox though.
I am targetting 1.3.6+
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
