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
