cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Clarification on converter concept
Date Thu, 05 Jul 2007 12:24:38 GMT
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

>> 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.

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

For the converters we have the CForms convertors today,

the most imortant methods are

ConversionResult convertFromString(String value, Locale locale, 
FormatCache formatCache);
String convertToString(Object value, Locale locale, FormatCache 

It is not that different from the setAsText and getAsText methods of the 
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

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.

The BeanWrapper 
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.



View raw message