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]
