Re: [Springframework-developer] Binding Locale to threadlocal

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

Colin,
=20
Do you have a concrete use case for this? I've personally not needed =
implicit locale access in the middle tier, and I'm not sure if business =
objects should rely on a thread-bound locale. I tend to pass the locale =
explicitly as argument in my business methods, which can then in turn be =
passed to a MessageSource or MessageSourceAccessor.
=20
One advantage of an explicit locale argument is that the choice of =
locale for a specific operation is completely up to the view layer. For =
example, a report can be generated in English (through passing the =
English locale to a business operation as explicit argument), despite =
the user interface language (as determined by LocaleResolver in Spring =
web MVC) being German.
=20
I guess we should first discuss whether we actually want to build =
thread-bound locale resolution into the framework, which people would =
see as general recommendation for such an approach. I tend to recommend =
explicit locale arguments instead... There is an argument that a =
specific locale for a given servlet request only applies to the web user =
interface itself, not necessarily to all business operations triggered =
by it.
=20
On the other hand, if many of your business operations would end up with =
explicit locale arguments, an implicit locale context does make sense, =
possibly combined with a general user context that also contains =
authorization info etc. A custom HandlerInterceptor should be able to =
expose the current Locale (or a LocaleAccessor delegating to the =
LocaleResolver) via such a ThreadLocal; this does not necessarily have =
to be built into DispatcherServlet itself.
=20
Open for discussion :-)
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: So 05.12.2004 21:56
An: spr...@li...
Betreff: [Springframework-developer] Binding Locale to threadlocal



I'm thinking of the best strategy for making the locale available to the
MessageSourceAccessor, as per SPR-485:
  http://opensource.atlassian.com/projects/spring/browse/SPR-485
This would probably be a TheadLocal that the locale is bound to. The
question is what the best strategy to do this is. I suppose
DispatcherServlet could just bind the locale to a threadlocal, using the
configured LocaleResolver, before dispatching. The problem here is that
it won't pick up a changed locale as a result of a setLocale call on the
localeresolver by the web code. Alternately, a ControllerInterceptor
would have the same limitation, and would also have to be configured in
front of every controller. What I am thinking would perhaps work though
is something like a new Interface called LocaleAccessor. The
implementation would be a JavaBean, and would be bound to the thread by
the dispatcher. What it would hold would be both the Servlet Request,
and also the LocaleResolver. When asked to get the Locale, it would be
able to use the normal localeresolver, since it would also have the =
request.

The whole point of this is so that non-view layer code can have access
to locale resolution, in a similar fashion to view layer code.

Can anybody think of a better mechanism?

Colin



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer