You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Kris Schneider <kr...@dotech.com> on 2003/02/26 14:45:48 UTC
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.
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 <ma...@dotech.com>
D.O.Tech <http://www.dotech.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Design clarification for locale handling
Posted by Kris Schneider <kr...@dotech.com>.
David's already asked me to put up or shut up ;-), but for the record...
Even if no requests ever get processed by ActionServlet, having HtmlTag just use
RequestUtils.retrieveUserLocale will still do the right thing (i.e. return a
locale based on the Accept-Language header, or the default locale for the
server). I don't see how that would break localization behavior.
Quoting "Craig R. McClanahan" <cr...@apache.org>:
> On Wed, 26 Feb 2003, Kris Schneider wrote:
>
> > Date: Wed, 26 Feb 2003 08:45:48 -0500
> > From: Kris Schneider <kr...@dotech.com>
> > Reply-To: Struts Developers List <st...@jakarta.apache.org>
> > To: Struts Developers List <st...@jakarta.apache.org>
> > 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 <ma...@dotech.com>
> > D.O.Tech <http://www.dotech.com/>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
--
Kris Schneider <ma...@dotech.com>
D.O.Tech <http://www.dotech.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: Design clarification for locale handling
Posted by Mitchell Morris <mm...@mindspring.com>.
That still leaves a (potential) bug, in that a page with '<%@ page
session="false"%>' and '<html:html locale="true">' will create a session. It
seems to me that HTML should respect the page and/or servlet configuration
with respect to session creation, and that checking is currently not being
done. If RequestProcessor isn't being invoked and that's allowed, then
perhaps RequestProcessor is the wrong place for the
session-creating-and-locale-setting logic ... would RequestUtils be a better
home?
i'm-often-wrong-though-ly y'rs,
+Mitchell
[snip]
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Design clarification for locale handling
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 26 Feb 2003, Kris Schneider wrote:
> Date: Wed, 26 Feb 2003 08:45:48 -0500
> From: Kris Schneider <kr...@dotech.com>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>
> To: Struts Developers List <st...@jakarta.apache.org>
> 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 <ma...@dotech.com>
> D.O.Tech <http://www.dotech.com/>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org