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 14:14:53 GMT
Grzegorz Kossakowski skrev:
> Daniel Fagerstrom pisze:
>> Grzegorz Kossakowski skrev:
> Yes, but I really didn't get the idea fully. Now I think that it may 
> be just a lack of use cases for converter. Would you be so kind to 
> provide some examples how it could work in particular cases and how it 
> would be helpful for Cocoon developer?
> Sometimes abstract explanations hide the basic idea, actually.
Didn't my examples from CForms and CTemplate below help you?

Anyway, say that you have a couple of dates in your model bean that you 
would like to render on a web page using CTemplate. Then you currently 
would need to write something like (haven't checked the details):

<jx:formatDate value="${myobj.startDate}" dateStyle="short" locale="${cocoon.request.locale}">

for each date. That is of course quite OK to write, but it clearly 
clutters the code, and it is not that obvious for a non developer. With 
converters it would be more like:




for the default formatting.

And for CForms you would use exactly the same notation.
>> 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:patterns>
>>    <fd:pattern>MM/dd/yyyy</fd:pattern>
>>    <fd:pattern locale="nl-BE">dd/MM/yyyy</fd:pattern>
>>    <fd:pattern locale="fr">dd-MM-yyyy</fd:pattern>
>>  </fd:patterns>
>> </fd:convertor>
>> see 

>> for each date field in your form definition (maybe there are some 
>> more convenient way to do it with form libraries?).
> AFAIR, using form libraries is the solution you look for in this case.
Maybe, but in that case you have one way of handling formating for forms 
and another way for templates. And you would need two configurations 
instead of one. Also from a conceptual standpoint it is better to 
separate the rendering part (template) and the model part (form 
definition). See my abstract text ;) for more 
about the model-rendering separation.

>> In CTemplate you instead use special tags 
>> With these constructions a localized Cocoon webapp becomes cluttered 
>> with localization code. 
> Are there any use-cases apart form Date/Number/Currency conversion?
I think those are the main use cases. But I think it should be plugable 
so that people are able to write converters for there own classes. As 
you can see in,

cforms contains a number of different convertors.

>>> 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 
> So converter is just a wrapper for configured DateFormat, right?
A date converter would be that, yes.


View raw message