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 Wed, 04 Jul 2007 16:30:19 GMT
Grzegorz Kossakowski skrev:
> Hello,
> I'm glad to see that we agreed on design of OM, now I would like to 
> focus on converter concept.
> First of all, I would like to know which form should be preferred: 
> "converter" or "convertor". Since both are valid (according to
> I'm not really sure which one I should pick.
Convertor was from CForms, converter might be a better name.

> Now I must admit that I'm not sure if I understand converter concept. 
> Let me explain my current understanding.
> Basically, converter for certain type is a class that performs 
> conversion between that type and its string representation. The 
> converter is locale-aware so string produced by converter may depend 
> on user's locale (e.g. Date representation).
Something like that. You find some background in and Also I think 
we already discussed converters while discussing your GSoC application.

The main usage is localization of string representations of dates and 
numbers. This is needed both for CTemplate and CForms. For CForms the 
converter needs to be bidirectional as well.

Of course there already is possible to do localization in CForms and 
CTemplate but it is not that convenient. In CForms you need a 
declaration like

<fd:convertor type="formatting">
    <fd:pattern locale="nl-BE">dd/MM/yyyy</fd:pattern>
    <fd:pattern locale="fr">dd-MM-yyyy</fd:pattern>


for each date field in your form definition (maybe there are some more 
convenient way to do it with form libraries?).

In CTemplate you instead use special tags

With these constructions a localized Cocoon webapp becomes cluttered 
with localization code. There are certainly room for some improvements:

First, it would be better to have *one* localization method that could 
be used in both CForms and CTemplate (and possibly at other places), so 
it is enough to learn one method for  newcomer.

Second, it should be enough to declare the localized rules for getting 
from an object to its localized string representation in one place 
(configuration file), needing to do it for each use makes the code hard 
to maintain and read.

Third, there should be a default converter (possibly localized) for 
important data types, so you don't need to write anything at all in your 
forms or templates in most cases.

> It is perfectly valid to have more than one converter for particular 
> type, each one identified by unique, short identifier. Thanks to 
> converter concept following syntax:
> {jxpath:cocoon/request/parameters/date}#shortDate
> will be used to tell Cocoon that user expects 'date' request parameter 
> to be formatted as short date (whatever it means).
Short etc. is from DateFormat

> For each type it is possible to define default converter and it is 
> assumed that Cocoon ships with set of default converters for 
> primitive, common types.


View raw message