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 Tue, 17 Jul 2007 11:55:05 GMT
Joerg Heinicke skrev:
> On 14.07.2007 15:55, Daniel Fagerstrom wrote:
>>> Doesn't this variant selection go very much into the direction of
>>> assumption about the data type?
>> It is up to the user. The user could as an example have a "short" 
>> variant for the short form of a couple of different data types.
> This argument is a bit lousy, isn't it? ;-)
I don't see that an assumption about what kind of concept you are 
accessing should be a problem, but we should definitively avoid low 
level assumptions. As an example: I don't see any problem with letting 
the template author knowing that something is a date, and optionally 
make it possible to chose between different visual presentations. But 
the template author should not need to be aware about differences 
between java.sql.Date, java.util.Date and a custom date type.

>>> It also completely decouples the object-to-string conversion from 
>>> the templating while with the "select a variant"-approach in the 
>>> template the conversion can not be done without the template.
>> That is an implementation detail. We have an object model that an 
>> expression language can be applied on where the result in turn can be 
>> converted by a converter and the result in turn can be used in a 
>> template. We have 4 different parts that can be used both together 
>> and in parts if implemented in the right way.
> For me it's 1. object model, 2. object-to-string conversion and 3. 
> referencing the value in the template via the EL. If the EL influences 
> the conversion 2. and 3. are coupled. That's not just an 
> implementation detail.
No, the object to string conversion is done on the result from the EL, 
not the other way around. The "#variant" is not part of the EL, it is 
part of a separate "converter language".



View raw message