Menu
▾
▴
Fw: [Springframework-developer] Explicit locales
|
From: Rod J. <rod...@in...> - 2003-02-21 11:55:12
|
Reply-to again!
----- Original Message -----
From: "Rod Johnson" <rod...@in...>
To: "JP PAWLAK(Tiscali)" <jp....@ti...>
Sent: Friday, February 21, 2003 7:58 AM
Subject: Re: [Springframework-developer] Explicit locales
> Jean-Pierre's interface-based solution (which I hadn't seen because the
> attachment was too big and I had to approve it for it to appear) is along
> the lines I'd envisaged. Consistent with the Spring way, as he points out.
>
> One of the implementations of the interface could simply use a session att
> as Juergen suggests.
>
> I think it should go into the controller servlet.
>
> Where do we cache locale information? I'm not keen on creating a session
if
> one doesn't exist, as I think Struts does, because this can get us into
> replication issues in otherwise stateless web apps.
>
> The LocaleLocator is also really a manager. Maybe one implementation could
> use sessions, another could use cookies etc. As Jean-Pierre has done, the
> bean factory is a perfect way to choose.
>
> Rod
>
> ----- Original Message -----
> From: "JP PAWLAK(Tiscali)" <jp....@ti...>
> To: "Spring Developers (E-mail)"
> <spr...@li...>
> Sent: Friday, February 21, 2003 7:03 AM
> Subject: TR : [Springframework-developer] Explicit locales
>
>
> Envoyé : jeudi 20 février 2003 22:50
> À : 'Trevor Cook'
> Objet : RE : [Springframework-developer] Explicit locales
>
>
>
> I use a solution near of yours but with a more generalist approach. To
> keep the users locale, different possibilities exist: session, cookie,
> URL. But each solution can be handled knowing the request object. So I
> use a bean for implementing the effective strategy in the way of the
> general spirit of Spring.
>
> 1) Create a simple interface like this:
>
> public interface LocaleLocator {
>
> Locale getSessionLocale(HttpServletRequest request);
>
> void setSessionLocale(HttpServletRequest request, Locale
> sessionLocale);
>
> }
>
> 2) Create an implementation class which in your case handles with the
> cookies, but which can use the session or what method you like.
>
> 3) Overriding the ControllerServlet to use a LocaleLocator property with
> at least the setter, so the implementation class can be done in the
> servlet-configuration file.
>
> <bean name="localeLocator" singleton="true"
> class="perso.jpp.fwk.web.LocaleLocatorImpl" />
>
> <bean name="jstlHandler" singleton="true"
> class="perso.jpp.fwk.web.JstlHandlerImpl" >
>
> <property name="bundleName">achappro</property>
>
> </bean>
>
>
>
> code added in declaration part:
>
> // Added by JPP
>
> /** The bean name allowing the user session locale to be retrieved
> */
>
> public static final String LOCALE_LOCATOR = "localeLocator";
>
>
>
> /** The bean name allowing the jstl ressouece bundle to be set */
>
> public static final String JSTL_HANDLER = "jstlHandler";
>
>
>
> /** LocaleLocator used by this servlet
>
> * If not provided, request.getLocale() will be used instead */
>
> private LocaleLocator localeLocator;
>
> // End added
>
>
>
>
>
> code added in ControllerServlet (or descendent) at end of
> initFrameworkServlet :
>
> initViewResolver();
>
>
>
> // Added by JPP
>
> try {
>
> localeLocator = (LocaleLocator)
>
>
> getWebApplicationContext().getBean(LOCALE_LOCATOR);
>
> logger.config("localeLocator found in servlet '" +
> getServletName()
>
> + "' : " + localeLocator.getClass().getName());
>
> } catch(Exception e) {
>
> localeLocator = null; // Not required as it should
> yet been null
>
> logger.config("No localeLocator found in servlet '" +
> getServletName() + "', request Locale will be used.");
>
> }
>
> // Jstl handling
>
> // Put only in a subclass ? But Jstl is ageneric use
>
> // The ApplicationContextAware doesn't provide an access to
> the servletContext
>
> // It's the reason of an initialisation here. Exists a best
> approach ?
>
> try {
>
> JstlHandler jstlHandler = (JstlHandler)
>
>
> getWebApplicationContext().getBean(JSTL_HANDLER);
>
> jstlHandler.setServletCtx(this.getServletContext());
>
> logger.config("jstlHandler found in servlet '" +
> getServletName()
>
> + "' : " + jstlHandler.getClass().getName());
>
> } catch(Exception e) {
>
> logger.config("No jstlHandler found in servlet '" +
> getServletName());
>
> }
>
>
>
> // End added
>
>
>
> 4) As you can see, I handle I a same way the definition of locale and
> bundle for JSTL.
>
> 5) The LocaleLocator can be donated by beanref property to objects which
> have to know the current locale having the request object.
>
>
>
> I hope this will be a useful add-on in this discussion. I suggest to
> integrate a such behaviour in the original ControllerServlet as thes
> needs are very generally.
>
>
>
> Regards,
>
> Jean-Pierre
>
>
>
> -----Message d'origine-----
> De : spr...@li...
> [mailto:spr...@li...] De la
> part de Trevor Cook
> Envoyé : jeudi 20 février 2003 21:38
> À : Spring Developers (E-mail)
> Objet : RE: [Springframework-developer] Explicit locales
>
>
>
> It sounds like you're on the right track, and your approach should work
> for my stuff. I've already implemented some of this (code below) by
> overriding ControllerServlet and checking for a cookie in doService
> before passing control up. I store the locale in a persistent cookie so
> that no session is created for simple site browsing, and to remember
> chosen language for future visits. I'm sure my approach could be
> improved alot, but it's just a prototype (so I could get my html guy to
> start working).
>
> When you're implementing it, a few suggestions/ideas/requests. If this
> is put into the framework, you probably want to allow the developer to
> specify whether to make it cookie or session-based. If it is
> cookie-based, you'll probably also need to allow the developer to
> specify browser or persistent (including max age).
>
> Trevor D. Cook
>
>
>
> public class LocaleServletController extends ControllerServlet {
>
> public static final String LOCALE_HANDLE = "locale";
>
> protected void doService(
>
> HttpServletRequest request,
>
> HttpServletResponse response,
>
> boolean debugMode)
>
> throws ServletException, IOException {
>
> String locale = request.getParameter(LOCALE_HANDLE);
>
> if (locale != null) {
>
> logger.info("Setting locale to: " + locale);
>
> setLocaleCookie(request, response, locale);
>
> } else {
>
> getLocale(request);
>
> }
>
> super.doService(request, response, debugMode);
>
> }
>
> private void getLocale(HttpServletRequest request) {
>
> Cookie[] cookies = request.getCookies();
>
> int cookiesSize = cookies.length;
>
> for (int i = 0; i < cookiesSize; i++) {
>
> if (LOCALE_HANDLE.equals(cookies[i].getName())) {
>
> String localeCookie = cookies[i].getValue();
>
> setLocale(request, localeCookie);
>
> }
>
> }
>
> }
>
> private void setLocaleCookie(
>
> HttpServletRequest request,
>
> HttpServletResponse response,
>
> String localeString) {
>
> Locale locale = setLocale(request, localeString);
>
> Cookie localeCookie = new Cookie(LOCALE_HANDLE, localeString);
>
> if (locale.equals(request.getLocale())) {
>
> localeCookie.setMaxAge(-1);
>
> } else {
>
> localeCookie.setMaxAge(365 * 24 * 60 * 60);
>
> }
>
> response.addCookie(localeCookie);
>
> }
>
> private Locale setLocale(
>
> HttpServletRequest request,
>
> String localeString) {
>
> Locale locale =
>
> new Locale(localeString.substring(0, 2), localeString.substring(2));
>
> request.setAttribute("locale", locale);
>
> return locale;
>
> }
>
> }
>
>
>
>
>
> -----Original Message-----
> From: jürgen höller [werk3AT] [mailto:jue...@we...]
> Sent: February 20, 2003 3:21 PM
> To: Spring Developers (E-mail)
> 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
>
>
>
>
> ---
> 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
>
>
>
>
|
