Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (herse.apache.org: local policy)
Message-ID: <469CAE19.80102@nada.kth.se>
Date: Tue, 17 Jul 2007 13:55:05 +0200
From: Daniel Fagerstrom <danielf@nada.kth.se>
User-Agent: Thunderbird 1.5.0.12 (Windows/20070509)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Clarification on converter concept
References: <468AA7E9.7020902@tuffmail.com> <468AC988.60809@gmx.de>
 <468C2397.9060105@apache.org> <468F2540.2070109@gmx.de>
 <468FAE5E.6060509@nada.kth.se> <46954DEE.8040401@gmx.de>
 <46992A2A.50903@nada.kth.se> <469BBFE7.30007@gmx.de>
In-Reply-To: <469BBFE7.30007@gmx.de>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 7bit

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".

...

/Daniel