Re: [Springframework-developer] Explicit locales

[Rod J. <rod...@in...>]

Guys,

I was aware that this was something that needed to be addressed. Certainly
it's a 1.0 thing.

Juergen's proposal seems simple and effective. I think it's what Struts
does.

Trevor's suggestion of a "hook" is interesting. It would be great for
testing etc. to be able to configure it flexibly. Imagine if a user's locale
preferences were even held in a DB? Can we parameterize based on a
LocaleProvider interface? (Haven't had time to read Trevor's code--apologies
if you've already considered this).

Regards,
Rod

----- Original Message -----
From: "jürgen höller [werk3AT]" <jue...@we...>
To: "Spring Developers (E-mail)"
<spr...@li...>
Sent: Thursday, February 20, 2003 8:20 PM
Subject: Re: [Springframework-developer] Explicit locales


Trevor,

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.

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.

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.

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.

Regards,
Juergen



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



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.

4. Any other ideas?

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


---
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