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
