RE: [Springframework-developer] Explicit locales

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

The reason I had setLocale was to allow a Controller access to change the
explicit locale.  I think the easiest way to explain this is with my
understanding of how this should work with a "cookie" implementation.

When a request is made, it goes into the ControllerServlet.  The
ControllerServlet than calls the CookieLocaleResovler resolveLocale.  In the
resolve method, it looks for a cookie.  If it exists, it sets the locale to
the value from the cookie.  If it doesn't exist, it uses the default
(browser) locale (from the request object).  However, this only works if the
cookie is ALREADY SET.  If there is no cookie it resorts to the default
locale.

This brings up how to set the cookie.  For my application, I will probably
have a query string parameter added to the url for the current page.  This
means that if you are on the "about" page and click the "french" button, you
receive the french about page.  Somebody else may have an explicit "french"
url which returns a page saying "thanks for choosing french".  Because
different applications might have different methods of allowing the user to
select the locale, they need to be able to set the cookie (or set the
session variable for the other implementation). To prevent this problem, we
could force applications to use a single method of setting the locale, but I
don't think this is flexible enough, so this brings us to how a Controller
would set the locale.

If we don't have a "setLocale" method, we need to expose internal
implementation details.  If you use a cookie version, you need to know the
cookie name used by the resolver, create the cookie, and make sure that the
locale for the CURRENT REQUEST being handled will be updated (see
explanation of this below).  However, a session implementation will need to
know the name of the session attribute used by its resolver, add the locale
to the session, and again ensure the current request locale.  Because these
2 implementations have different ways of being set, the controller which
sets them is then bound to the specific implementation (cookie / session).

If we have a "setLocale" method, the Controller simply calls the interface
setLocale method, and the specific implementation sets the appropriate
cookie /session.  This has the benefit of allowing each application to
decide how to allow users to explicitly set a locale, but does not tie the
Controller to a specific implementation.  This also allows them to change
from a cookie resolver to a session resolver by modifying the class in the
config file without touching code.

I may be misunderstanding how you plan to implement it, but the way I would
implement it had the problem I've just described, prompting the third
"setLocale" method.

Above I mentioned "make sure that the locale for the CURRENT REQUEST being
handled will be updated".  When I did my prototype implementation, I found
that I would set the cookie and then return a page, but the language
wouldn't change.  On review I noticed the following sequence of events.
	- request sent to servlet controller
	- servletController checks for cookie and sets locale
	- controller checks if locale in query string and sets cookie
	- controller returns page
Because the servletController set the locale before controller processing,
setting the cookie didn't change the locale for the current request.  If I
moved the servletController check after the controller is done, it isn't
able to do any processing based on the explicitly set locale.  This pointed
out my oversight that when I set the cookie I also need to to set the
current locale (even though the servletController previously made the
check).  This allows controllers to know which locale was explicitly set,
but also allows them to change that value.  You guys may have thought of
this problem already, but it caught me off guard (and cost me 20 min to find
the source :( ).

Trevor D. Cook

-----Original Message-----
From: jürgen höller [werk3AT] [mailto:jh...@we...]
Sent: February 22, 2003 1:57 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Explicit locales

Trevor,

The name "LocaleResolver" is fine, and naming the retrieval method
"resolveLocale" too, analogous to ViewResolver. But I'm not sure what you
mean concerning the setLocale method and its Locale parameter: We need a way
of telling the resolver that the user has chosen a specific locale - just
like you note in your 4th paragraph. I.e. one resolution method and one
modification method.

I also prefer the "viewResolver" bean reference, looked up by the
ControllerServlet, without individual LocaleResolver instances per
controller. Of course, controllers need a way to both retrieve and set the
current locale. So we should probably propagate the ControllerServlet's
LocaleResolver instance via HandlerMapping to Controller instances that
implement LocaleResolverAware (as I've already proposed), analogous to
ApplicationContext and ApplicationContextAware.

Concerning LocaleResolver implementations: Maybe call the default
implementation "BrowserSettingLocaleResolver"? And yes, we should provide a
"SessionLocaleResolver" and a "CookieLocaleResolver" out of the box.

I like that locale resolution support: fairly sophisticated, but still
reasonably simple!

Juergen

	-----Ursprüngliche Nachricht----- 
	Von: Trevor Cook [mailto:tc...@in...] 
	Gesendet: Sa 22.02.2003 17:30 
	An: spr...@li... 
	Cc: 
	Betreff: RE: [Springframework-developer] Explicit locales

	Naming - I agree that LocaleHandler is confusing. I like
LocaleResolver, since it is consistent with the the ViewResolver classes. 

	Interface - really good, but I don't think it's necessary to have
locale as a parameter of setLocale, since that method will be determining
the actual locale. What value be passed by the ControllerServlet for this
parameter?  Maybe it would be less confusing to make the signature:

	        Locale resolveLocale(HttpServletRequest request,
HttpServletResponse response); 
	The signature now makes it clear that we are not "setting it" so
much as asking the method to determine how it should be set.  It also
matches the viewResolver usage. An additional "setLocale" method with the
signature you provided:

	        void setLocale(HttpServletRequest request,
HttpServletResponse response, Locale locale); 
	could be used to explicitly override the Locale determined by the
resolveLocale method.  This would benefit Controller specific overrides
(addressed below).  As you noted, the response is necessary for cookie-based
implementations (good catch).

	Configuration - I think that loading it as a bean reference (like
"viewResolver") makes the most sense.  If we provide an access method, this
would allow individual Controllers to get a reference to the resolver and
override the locale using the setLocale method mentioned above.  I think the
ControllerServlet should handle the locale resolution rather than a
"LocaleHandler-per-Controller".  If someone needs "normal" locale handling,
I think the per-Controller method would require too much cut-n-paste type
code.  However, the exposed setLocale method would allow those who need to
set it on a per-Controller basis the ability to do so.

	DefaultImplementation - I think "ClientLocaleHandler" is too
general, since all LocaleHandlers (or LocaleResolvers as I prefer :) ) are
making decisions based on the client.  The default will be using the
servlets default mechanism, so maybe "ServletLocaleResolver" or
"RequestLocaleResolver" (although again, too me they're too general - I
can't think of a really good name).  We should also create additional
implementations for distribution such as the cookie and session based
versions, rather than requiring each client to code one themselves (although
they will have the oppurtunity to do so).

	Great analysis Juergen! 

	Trevor D. Cook 

	---
	Outgoing mail is certified Virus Free.
	Checked by AVG anti-virus system (http://www.grisoft.com).
	Version: 6.0.456 / Virus Database: 256 - Release Date: 2/18/03

NHY޵隊X'u'$ح"wzyN\jkz+jw_bnWמv+h*.quڲ׫
"Z0.fj+xTD}k$뉩p
%v+\oy+䩮)~{
+ׯzZ)zXX*kxŠuޖ^X(~zwilqzlX)ߣ))~{
+ׯzZ)

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.456 / Virus Database: 256 - Release Date: 2/18/03

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.456 / Virus Database: 256 - Release Date: 2/18/03