RE : [Springframework-developer] themes

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

Hi Juergen,

I'm very happy with your changes. Sorry to give you work on each idea
:-(, but the simplicity of the current model shows the good abstraction
level is reached. I just believe I lack some experience to finish my
work in a high level of finishing touches as you can. I hope that you
even have less work as starting from scratch ;-).

Jean-Pierre


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

Hi Jean-Pierre,

I've reworked your current implementation quite a bit, and committed it
to the theme branch. I'm happy with it now, I hope you are too... :-)

The most obvious change is the introduction of a Theme interface,
consisting of "getName()" and "getMessageSource()". ThemeSource just has
"Theme getTheme(String themeName)" anymore. A theme is effectively a
MessageSource that is specific to a theme name, as indicated by the 3
getTheme() methods that all match their getMessage() counterparts, just
with a theme name parameter. So this seems to be the most appropriate
design for me.

This allows for a very straightforward ThemeTag implementation, just
extending MessageTag and overriding the default getMessageSource with
the current theme's one! The UI contexts are now extremely thin, and the
current ResourceBundleThemeSource is simply a factory for theme-specific
ResourceBundleMessageSources.

Furthermore, I've dissolved ConcreteThemeSource, and introduced a
UiApplicationContextUtils helper class that features a
initThemeSource(ApplicationContext) method, used by both
AbstractXmlUiApplicationContext and StaticUiApplicationContext. This
means less code, and is in line with the WebApplicationContext
implementation strategy and WebApplicationContextUtils.

The PagedList demo application should work unchanged. There's just one
small fix in the cookie names that has nothing to do with the above
changes: It's
"...CookieLocaleResolver.LOCALE"/"CookieThemeResolver.THEME" now,
instead of the previous "SessionXxxResolver" names.

BTW, instead of directly setting the respective cookies via JavaScript,
you could make PagedListController implement LocaleResolverAware and the
new ThemeResolverAware. Then the controller could call
setLocale/setTheme in case of respective requests, triggered by certain
HTML links. Note that this implementation strategy allows for seamlessly
changing the LocaleResolver/ThemeResolver implementation, e.g. from the
cookie to the session version!

Please go ahead with the test suite and the Javadocs! If we don't find
any obstacles anymore, I'm all for integrating themes into the upcoming
0.9 release. This means that if you manage to finish it by the end of
the week, you can promptly join the theme branch into the main branch,
so that we will have one single codebase again.

Regards,
Juergen