cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [RT] Attribute Rendering and CForms Convertors
Date Fri, 05 Nov 2004 14:50:01 GMT
Jonas Ekstedt wrote:

>On Fri, 2004-11-05 at 14:02 +0100, Daniel Fagerstrom wrote:
>>>If I would be able to choose convertors I might decide IN VIEW ITSELF 
>>>that that specific model value should be coloured/pretty 
>>>printed/rendered according to some specific logic. As long as this 
>>>logic has read-only access to model and performs steps to produce some 
>>>rendering I do not find it SoC break.
>>Seem like an excelent idea to me. I think it could be analog to the use 
>>of the class attribute in HTML to give hints to CSS about styling.
>>We could have something like:
>>  ${month/balance?class=financialValue}
>>then the finacialValue rule for convertion is used if there is one 
>>otherwise the default rule is used. There is no doubt room for 
>>improvement of the syntax ;)
>>A functional syntax as Sylvain prpoposed would also be possible:
>>  ${convert(month/balance, 'financialValue')}
>>but I percieve the convertor as something that not is part of the 
>>expression language (EL). The convertor is applied to the object that is 
>>returned from the EL engine, and the default convertor should always be 
>>applied on the object, so one shoudn't need to write
>>  ${convert(month/balance)}
>>to get the default conversion.
>Couldn't the above example be done better with tags instead? For
><mytag:date value="${todaysDate}"/>
>This tag could then render as:
><mytag:date locale="se" value="2004-11-05"/>
>or a financial value could use the tag:
><mytag:financial-value value="${month/balance}"/>
>that is rendered as:
><mytag:financial-value value="-10" currency="SEK" positive="false"/>
>This way you avoid complicating the expression language. As I see it the
>only time you're going to do value conversion in your template is when
>outputting values, as opposed to testing values. And if you're merely
>outputting values you can just as easily do conversion with tags
>specifying how to convert your values.
>// Jonas
It could maybe done like that also. The point of puting it in the 
expression language (EL) is that if we have a common interface for using 
ELs, we can reuse the EL with converter component in all places where we 
need an EL in Cocoon without having to reimplement a number of 
conversion tags in each case. Tags are also harder to use when you want 
a value from your EL whithin an attribute. You could maybe use something 
like <xsl:attribute .../> but that is more complicated. IMO it is god if 
you get the default conversion without having to write anything extra.

My current view is that we have an converter component that is plugged 
in in an adapter in front of the EL engine. The converter component is 
configured with a set of  default, locale specific and view class 
specific rules:

<convertor-set id="default">
  <datatype type="java.util.Date">
    <convertor type="formating" pattern="MM/dd/yyyy"/>
    <convertor locale="nl-BE" type="formating" pattern="dd/MM/yyyy"/>
    <convertor locale="fr" type="formating" pattern="dd-MM-yyyy"/>
  <datatype type="java.lang.Double">
    <convertor type="formating" style="number"/>
    <convertor class="financial" type="xml">
        <when test="$value>=0">
          <span class="black">
            <convertor type="formating" style="currency"/>
          <span class="red">
            <convertor type="formating" style="currency"/>



View raw message