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 20:58:55 GMT
Grzegorz Kossakowski skrev:
> Daniel Fagerstrom pisze:
>> Grzegorz Kossakowski skrev:
>>> Daniel Fagerstrom pisze:
> I had a feeling that there is much more besides Date/Number/Currency 
> formatting but now I think that I was suffering from over-generalization 
> problem. The converter concept is that simple how you describe it but 
> it's not wrong because it solves very concrete problem.

Nothing spectacular this time ;) But improving usability is consists 
mainly of lots of small improvements.

> Now I think that I fully get the idea and we can focus on discussing how 
> to implement it.
>> 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:
>> ${myobj.startDate#short}
>> and
>> ${myobj.startDate}
> Personally, I prefer ${myboject.startDate}#short syntax because choosing 
> converter should not be part of expression (it would be hard to 
> distinguish where expression part ends and converter name begins in some 
> cases). The syntax would also imply that conversion is performed after 
> obtaining value (object) by evaluating the exception.

That would be the case if expressions with converter variant modifiers 
only was used alone as attribute values. But remember that expressions 
in CTemplate can be embeded in text as well, e.g.:

<p>The start date is ${myobj.startDate#short}.</p>

In such cases having the modifier outside the expression would be harder 
to parse. We chose '#' as a separator as it didn't seem to have any 
significant meaning in the expression languages we had in mind when the 
converters where discussed. We can always introduce some escaping 
mechanism "##" e.g. for cases when a literal '#' is needed as part of an 


View raw message