Re: [Springframework-developer] Explicit locales

[<jue...@we...>]

Trevor,
=20
I've noticed that issue too. We definitely need support for a manually =
set locale in the session, already for 1.0. I consider 1. the only =
viable option but I think of a very easy and generic way: Why not just =
define a Spring standard name for a session attribute that can contain a =
Locale instance? The ControllerServlet could first check the session for =
such an attribute and fall back to the request locale.
=20
A custom application will probably not support changing the locale with =
every possible action but rather with a special one controller URL. That =
controller implementation could put a respective attribute into the =
session, with the given standard name, and update user preferences in =
the database or set a respective cookie if desired. Of course, the =
user's locale has to be retrieved for a new session - that could happen =
after login in a login controller, or in a custom filter that checks for =
a certain cookie.
=20
So the minimal framework support needed seems to be the definition of a =
standard name for a session locale, and checking the session when =
determining a view in the ControllerServlet. Of course, custom =
applications can not only set that locale but also retrieve it in =
controllers that perform locale-specific actions.
=20
I'm currently in the process of polishing Spring's web part (probably =
taking over responsibility for it, at least for 1.0), so I could add =
such locale support easily. Would the outlined approach be sufficient =
for you? If yes, I will add that support prompty, probably commiting the =
changes at the beginning of next week.
=20
Regards,
Juergen
=20
=20

	-----Urspr=FCngliche Nachricht-----
	Von: Trevor Cook [mailto:tc...@in...]=20
	Gesendet: Donnerstag, 20. Februar 2003 03:55
	An: Spring Developers (E-mail)
	Betreff: [Springframework-developer] Explicit locales
=09
=09

	I have a business requirement of handling multiple locales.  =
Specifically, I live in Canada, and the application must be available in =
French and English.  However, due to multiple users on a single =
computer, we cannot rely solely on the users locale settings.  What we =
need to do is default to the users locale, but provide them with the =
ability to override these settings (probably by clicking an =
"English/French" link).

	Anyway, the framework question I have is "is there anyway to do this =
currently"?  Looking at the controller servlet, it returns a view based =
on "request.getLocale()".  This can't be changed, so I can't see any way =
to customize/change it.  My ideas are:

	1. Have an explicit object in the request attribute for the locale with =
a "hook" to define how the default is determined (request locale, =
cookie, session, etc.).  The view (or any other locale "lookup") would =
be based on this attribute.

	2. Wrap the request/response objects in the control servlet, and =
provide hooks for these wrappers (which could override the getLocale() =
method).

	3. Have the view return a generic view, and have the view contain =
code/taglibs which do the locale stuff in it.=20

	4. Any other ideas?=20

	My "rating" of my own arguments is that 1 is the best since it =
abstracts the locale to the start of the servlet request as an initial =
parameter (which is how I consider it).  2 requires a lot of =
customization to support what appears to be something others might use =
(however, the ability to override other methods might be desirable).  3 =
is ugly code, and removes all the benefits of Rod's framework for =
seamlessly handling the locale issues.

	We probably can't make any of these changes for the 1.0 release (if we =
can great, but I'm trying to be realistic) but I was looking for some =
ideas and counter-arguments.  I need to go ahead with this project (I'm =
actually waiting on this issue right now, but I think I've bought myself =
till Monday :) ) so I'll probably need to make my own modifications to a =
local copy of the code, but if my direction makes sense to everyone, I =
can probably polish/generalize my changes and roll it into the main =
stream in a future release.

	Trevor D. Cook=20


	---
	Outgoing mail is certified Virus Free.
	Checked by AVG anti-virus system (http://www.grisoft.com).
	Version: 6.0.449 / Virus Database: 251 - Release Date: 1/27/03
	 =20