I'll open an enhancement request against 2.0 so we can consider this issue when backwards compatibility doesn't matter as much.
David
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 <mailto:[EMAIL PROTECTED]> D.O.Tech <http://www.dotech.com/>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
