The usage of Spring in Cocoon

[Joerg Heinicke <jo...@gmx.de>]

Hello Spring team,

I write this message more or less on behalf of the Apache Cocoon 
(http://cocoon.apache.org) team. I don't know if somebody of you follows 
Cocoon's development: We have changed the internal container Cocoon is 
based on from Apache Avalon ECM to Spring for Cocoon 2.2. I used the 
quite common subject since we have quite different issues.

First the technical ones. When we started to talk about some converter 
concept recently [1] we originally had some generalization of the 
converters in Cocoon Forms [2] in mind. I made the proposal to do it the 
Spring way using PropertyEditors. Unfortunately 2 issues arose: The 
first is about lacking internationalization support, the second about 
(let's call it) "inflexible" editor selection.

1. Cocoon is known to have sophisticated i18n support. The property 
editors are lacking any built-in i18n support, Spring does not add 
anything on top of it. It is considered to be implemented into the 
editors like for the CustomDateEditor:

new CustomDateEditor(DateFormat, boolean)

It is only the DateFormat that gets locale information, e.g. from the 
request in the initBinder() method of the controllers. Since that's 
necessary in every controller it scatters the editor setup through the 
application. The new way of registering PropertyEditors using 
PropertyEditorRegistrar makes this even completely impossible since it 
has no access to the request.

The CForms Convertor interface [3] has the locale in its methods 
convertFromString() and convertToString() in contrary to PropertyEditor 
[4] as you know. Our idea was know anyway to remove it from the actual 
converters to the registry. So the locale would be another property you 
can register a PropertyEditor to as it is done with "path". The 
PropertyEditorRegistry would need to be extended correspondingly which 
can even happen in a backwards-compatible way I guess. The 
BeanWrapperImpl would need to search for editors using the locale 
additionally.

What do you think about it? Is it something that could it even make it 
into Spring 2.1?

2. The second issue with Spring's converter infrastructure is about the 
selection of editors by "path". It is not possible to show one property 
in two different representations on one page, e.g. a date in "full" and 
"short" form according to DateFormat [5]. That's what I called 
"inflexible" above.

Our original approach was to use a "variant" in the expression language 
like ${myobj.startDate#short}. That could even make it into the current 
"path", so it's actually an extended understanding of "path". There is 
also an approach passing this "variant" information back to the request 
binder.

I only wonder if you had this possible requirement at any place in mind. 
How would you address the need for different representations of the same 
property in one page?

3. The third "issue" is about some enhancements Carsten Ziegler 
implemented for "providing support in common configuration issues when 
using the Spring framework". It's called spring-configurator [6] and is 
used in Cocoon, but it's not tied in any way to Cocoon except for the 
package name at the moment. It has additional support for configuration 
like running modes (selecting property files according to running modes 
like "test" or "production"), automatic selection of property files and 
bean configuration from standard directories. Additionally there is a 
bean map which adds all beans of a particular type to a map as shown in 
[7] without the need to register it by hand.

The scope of these components is a bit beyond Cocoon's actual scope. 
Furthermore all this stuff is of rather general use, so we wonder if you 
are interested in the one or the other component. A move nearer to 
Spring community seems to be natural.

What do you think about it?

Thanks for any exchanges of ideas with the Cocoon community in advance.

Regards,
Joerg

[1] http://marc.info/?t=118349219800006&r=1&w=4
[2] http://cocoon.apache.org/2.1/userdocs/widgetconcepts/datatypes.html
[3] 
http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/forms/datatype/convertor/Convertor.html
[4] http://java.sun.com/j2se/1.4.2/docs/api/java/beans/PropertyEditor.html
[5] http://java.sun.com/j2se/1.4.2/docs/api/java/text/DateFormat.html
[6] http://cocoon.zones.apache.org/daisy/cdocs-spring-configurator/
[7] 
http://svn.apache.org/viewvc/cocoon/trunk/core/cocoon-expression-language/cocoon-expression-language-impl/src/main/resources/META-INF/cocoon/spring/DefaultExpressionFactory.xml?view=markup