Jonas Ekstedt wrote:
On Fri, 2004-11-05 at 14:02 +0100, Daniel Fagerstrom wrote: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.
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 example:
<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
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>
<datatype type="java.lang.Double">
<convertor type="formating" style="number"/>
<convertor class="financial" type="xml">
<choose>
<when test="$value>=0">
<span class="black">
<convertor type="formating" style="currency"/>
</span>
</when>
<otherwise
<span class="red">
<convertor type="formating" style="currency"/>
</span>
</otherwise>
</choose>
</convertor>
</datatype>
</convertor-set>WDYT?
/Daniel
