On Wed, 26 Feb 2003, Kris Schneider wrote:

> Date: Wed, 26 Feb 2003 08:45:48 -0500
> From: Kris Schneider <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Design clarification for locale handling
>
> As a reference, this is a follow-on to bug 17371
> (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17371). While I understand
> David's rationale behind closing the bug, I really think the design is broken
> (and apparently has been since 1.0). So, instead of just reopening the bug, I
> thought it would be best to get some feedback from the development community.
>

The HTML tag does its own locale-setting (and therefore session creation)
because some people still set their apps up to all URLs directly to JSP
pages (bypassing the controller servlet, so that the locale setup it does
is also skipped).  Removing this would break the localization behavior of
any app that depends on it.

Craig

> With regard to locale, it seems like HtmlTag's responsibility should end at
> rendering the <html> tag's "lang" attribute. As it currently stands, it will
> also create a session and store a locale under Globals.LOCALE_KEY if its
> "locale" property is set to "true". Which means it's perfeclty legal to have
> configured <controller locale="false"/>, and then a JSP with <%@ page
> session="false" %> and <html:html locale="true"> and end up with having a
> session created and a locale stored in it.
>
> RequestProcessor.processLocale seems like the appropriate place to handle the
> session creation and locale storage. Any other entity that needs a handle to the
> locale can just call RequestUtils.retrieveUserLocale.
>
> Are there other places in the framework besides RequestProcessor.processLocale
> and HtmlTag.getCurrentLocale that also store the locale in the session?
>
> Would appreciate any feedback you can provide. Thanks.
>
> --
> Kris Schneider <mailto:[EMAIL PROTECTED]>
> D.O.Tech       <http://www.dotech.com/>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to