RE: [Springframework-developer] themes

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

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


-----Original Message-----
From: JP Pawlak [mailto:jp....@ti...]
Sent: Tuesday, June 17, 2003 11:05 AM
To: 'Rod Johnson'; j=FCrgen h=F6ller [werk3AT];
spr...@li...
Subject: RE : [Springframework-developer] themes


Hi Rod, Juergen,

Following the last Rod's proposal, I have committed a third version.
It's effectively cleaner and more powerful to create an intermediate UI
level.

Current state:

APPLICATION:
	Only adding the protected afterRefresh method.

UI:
	ThemeSource
	NestingThemeSource
UI-SUPPORT:
	ConcreteThemeSource
	AbstractXmlUiApplicationContext
	StaticUiApplicationContext

	The two lasts classes add theme capabilities on their respective
ancestror.

WEB:
	DispatcherServlet handles the ThemeResolver
	The ThemeResolver interface has moved in web.servlet.theme and
joined its implementations.

	XmlWebApplicationContext and StaticWebApplicationContext are as
original but extending the UI level classes instead of Application
level.

The core handling of the themes is now in the UI packages, except the
Theme resolving which is web specific. A theme resolving scheme will to
be added later for Swing and AWT applications.


Jean-Pierre


-----Message d'origine-----
De=A0: Rod Johnson [mailto:rod...@in...]=20
Envoy=E9=A0: lundi 16 juin 2003 22:58
=C0=A0: JP Pawlak; 'j=FCrgen h=F6ller [werk3AT]';
spr...@li...
Objet=A0: Re: [Springframework-developer] themes

I have committed in the theme branch a new version having no more
modification outer the web package. This is true with an exception: the
refresh method from AbstractApplicationContext calls a protected
afterRefresh method which by default does nothing.

[RJ] Sounds promising

The most war straightforward. Only the ThemeSource could not be directly
generically implemented. To avoid the core code, I created a
ConcreteThemeSource. The WebApplicationContext classes include a such
object and are delegating to him for the theme related requests. They
redefine also the new method afterRefresh to include the theme refresh.

[RJ] It's almost like we need a new UIApplicationContext.  A standalone
Swing or SWT app might also want themes, would want all generic app
context
stuff, but wouldn't want the web app context stuff.
ApplicationContext -> UIApplicationContext -> WebApplicationContext


In the Struts galaxy, Struts-layout implements themes, but the whole
library becomes quickly a nightmare as it uses extensively HTML
generation by JSP Tags and blocks in a poor Html/Css technology.
JBoss has also themes in his Nukes implementation. But here also bunches
of HTML are hard-coded.

[RJ] I think themes are a very promising area for Spring. I spend all
day in
messaging middleware (although I have a little web consulting coming
up),
but sure could have used this when I was at FT.com.

Juergen, can you decide on whether this makes 0.9? I think it's
definitely
good for 1.0, but I don't want to delay 0.9 and it's basically a
backward-compatible enhancement.

Regards,
Rod