Joerg Heinicke skrev:
On 03.07.2007 21:47, Grzegorz Kossakowski wrote:
...
The converter is locale-aware so string produced by converter may
depend on user's locale (e.g. Date representation).
Don't know. Read on ...
Locale awareness is part of the idea.
...
Thanks to converter concept following syntax:
{jxpath:cocoon/request/parameters/date}#shortDate
Does that one (and converters in any way) already exist?
In Cocoon we only have the "convertors" in CForms. The "converter
concept" is about improving the CForms convertors and making them
available in templates (and possibly in other places).
There is an old prototype https://issues.apache.org/jira/browse/COCOON-1345.
will be used to tell Cocoon that user expects 'date' request
parameter to be formatted as short date (whatever it means).
I ask because I don't consider that one a good idea. Not the syntax
itself, but the fact that you can "select" a particular converter.
Why? Read on ... :-)
Normally you don't choose what converter to use. The framework select
based on data type and locale. But for e.g. dates there are several
different string representations (short, medium, full and long or maybe
some custom format) that the template or form author needs to choose
between. To me it seem reasonable to have a syntax for making this
possible in e.g. the template.
...
Think so. But ... now the stuff I want to add.
I don't know if that topic has already been discussed. At least I
can't remember - but that might also be one of the unread old threads
in my inbox. If you start from scratch I want to suggest to have a
look at how Spring handles this before we invent anything new.
...
That was quite much, I hope you could follow. I'm really deep inside
Spring MVC at the moment :-) Feel free to ask where I should elaborate.
I didn't manage to follow all the technical details. But in general it
would of course be good to reuse the Spring stuff. The main hurdles is
that the Spring mechanism doesn't support locales in any systematic way
and that it is not obvious how to use it for a webapp that supports
multiple locales. While it clearly has a lot of overlap with what we
want for the new improved OM, expression handling and converters it is
far from an 1-1 mapping.
It would be nice if you could expand a little bit more on what
advantages in using the Spring stuff that you see.
Architecture
============
Anyway, let us discuss architecture a little bit so that we can be more
concrete about how the Spring stuff would fit in:
The "converter architecture" as I imagine it consist of three parts.
* Converters: that provides a bidirectional mapping between objects and
string representations of them.
* Converter registry: where converters are registered together with what
type they act on and optionally what locale they handle and maybe a
variant (the later for handling multiple representations). The registry
has a lookup method that finds the right converter based on data type,
locale and variant. The lookup method probably contains default
strategies and fall back methods for parameter combinations where no
converter is registered.
* Integration: The template and forms uses the converter registry for
finding the right converter for going from objects found with the
expression language to string representation and for converting form
input to the right kind of object.
Applying the architecture
=========================
Converters
----------
For the converters we have the CForms convertors today
http://svn.apache.org/repos/asf/cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/datatype/convertor/Convertor.java,
the most imortant methods are
ConversionResult convertFromString(String value, Locale locale,
FormatCache formatCache);
String convertToString(Object value, Locale locale, FormatCache
formatCache);
It is not that different from the setAsText and getAsText methods of the
PropertyEditor
http://java.sun.com/j2se/1.4.2/docs/api/java/beans/PropertyEditor.html.
An important differences are that the convertor depends on a locale
which the property editor doesn't. IMO it would be cleaner to have the
locale dependency in the registry instead of in the converter. Next the
convertor needs a format cache, this is IIRC because date and number
formating objects not are thread safe and takes some work to construct.
When the forms framework was written, thread locals where quite
inefficient, so an external cache was used instead. This is not a
problem in Java 1.4 so we could use a thread local cache and get rid of
the format cache in the API. Last the convertFromString returns a
ConversionResult while setAsText throws a IllegalArgumentException for
badly formated input strings. I haven't looked at the details and have
no opinion about this.
As a conclusion I think that PropertyEditors would work fine for us if
we find it worthwhile. Some effort is needed for integrating them in the
forms framework.
Converter Registry
------------------
The PropertyEditorRegistry
http://www.springframework.org/docs/api/org/springframework/beans/PropertyEditorRegistry.html
of the Spring framework, register and lookup "converters" based on class
and property path. For a Cocoon framework I would prefer looking up a
converter based on class, locale and variant, while I don't see any
obvious use cases for property path. So the fit between the
PropertyEditor lookup and our needs is not that obvious AFAICS.
Integration
-----------
The BeanWrapper
http://www.springframework.org/docs/api/org/springframework/beans/BeanWrapper.html
could be interesting as a "container" for the expression handling and
converter stuff in Cocoon. Then the forms framework and template would
connect to the object model through our custom BeanWrapper. In this case
we would have a custom implementation that could use our more general
plugable ELs as property path strings. Also here it is unclear what to
do with locale handling.
--- o0o ---
So as a conclusion: it would be nice to reuse the Spring stuff and there
are big overlaps, but especially for locale handling it is not obvious
to me how to use it. Then of course there is the question if it is
worthwhile to reuse.
WDYT?
/Daniel
