RE : [Springframework-developer] themes

[JP P. <jp....@ti...>]

Hi Juergen,

For now, the ControllerAdapter is a nice solution. I didn't remember the
Adapter mechanism despite of the discussions.

Nevertheless, I will no more be here for a week from this evening and
since today, I have no more access on the repository. As user, my
authentication is refused (I sent a support request at SourceForge). And
as anonymous, I can't see the theme branch.

Regards,
Jean-Pierre


-----Message d'origine-----
De=A0: j=FCrgen h=F6ller [werk3AT] [mailto:jue...@we...]=20
Envoy=E9=A0: vendredi 20 juin 2003 12:14
=C0=A0: JP Pawlak; Rod Johnson;
spr...@li...
Objet=A0: RE: [Springframework-developer] themes

Hi Jean-Pierre,
=20
You've got a very valid point indeed!
=20
LocaleResolverAware and ThemeResolverAware were introduced to propagate
LocaleResolver and ThemeResolver references to Controller
implementations, so that the latter can use the resolver instance to
change the locale resp. theme. This was meant analogous to
ApplicationContextAware. The propagation has the drawback that
HandlerMapping implementations need to be aware of the resolvers too.
=20
Until recently, the resolved Locale and the resolved Theme were bound to
the request as attributes, so one had to use the XxxAware interfaces to
get resolver references. I've changed that this week: Now the
LocaleResolver and ThemeResolver instances themselves get bound, to be
able to resolve a freshly changed locale or theme (i.e. just changed by
the current request). RequestContextUtils provides easy access to a
freshly resolved locale and theme via its "getLocale" and "getTheme"
methods.
=20
This makes LocaleResolverAware and ThemeResolverAware more or less
obsolete, so I'll remove them. New RequestContextUtils methods
"getLocaleResolver" and "getThemeResolver" will make access to the
resolvers as easy as possible (instead of manual request attribute
retrieval and casting). I'll commit this with some other polishing that
I've done in the tag implementations (and the new tag test suite!).
=20
Regarding locale and theme change support in every controller in the
application: This is somewhat similar to the authentication issue that
we discussed some time ago. The difference is that a Servlet Filter and
a custom HandlerMapping implementation aren't options, as the former
can't access the DispatcherServlet attributes, and the latter doesn't
get a HttpServletResponse reference. But you could use a custom
HandlerAdapter implementation, like as follows:
=20
public class LocaleAwareControllerAdapter extends
SimpleControllerHandlerAdapter {
  public ModelAndView handle(HttpServletRequest request,
HttpServletResponse response, Object handler) {
    LocaleResolver localeResolver =3D
RequestContextUtils.getLocaleResolver(request);
    ThemeResolver themeResolver =3D
RequestContextUtils.getThemeResolver(request);
    String newLanguage =3D request.getParameter("language");
    String newTheme =3D request.getParameter("theme");
    if (newLanguage !=3D null) {
      localeResolver.setLocale(request, response, new
Locale(newLanguage));
    }
    if (newTheme !=3D null) {
      themeResolver.setThemeName(request, response, newTheme);
    }
    return super.handle(request, response, handler);
  }
}

Register it in your DispatcherServlet's application context, and it
should get applied on every request dispatched by this servlet:
=20
 <bean id=3D"localeAwareAdapter"
class=3D"werk3.example.LocaleAwareControllerAdapter"/>
=20
On the occasion, I'm currently working on per-HandlerMapping
interceptors that should be able to achieve the same. I'd like to
separate the various roles in handler processing: mapping, interceptor,
adapter. In the above solution, the latter two are combined - I'd like
to solve this issue.
=20
Regards,
Juergen
=20
=20

	-----Urspr=FCngliche Nachricht-----=20
	Von: JP Pawlak [mailto:jp....@ti...]=20
	Gesendet: Fr 20.06.2003 09:39=20
	An: j=FCrgen h=F6ller [werk3AT]; 'Rod Johnson';
spr...@li...=20
	Cc:=20
	Betreff: RE : [Springframework-developer] themes
=09
=09