incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christophe Lombart <christophe.lomb...@gmail.com>
Subject Re: [jcr-mapping] converter design
Date Tue, 04 Oct 2005 13:47:06 GMT
On 10/4/05, Costin Leau <costin.leau@gmail.com> wrote:
>
> Hello again.
>
> I'd like to open another issue: the converters.
> 1. There is no Converter interface - this is one package where an
> interface is BADLY needed



There 3 kind of converters :
* ObjectConverter : convert a pojo object or bean fields
* AtomicTypeConverter : convert simple types
* CollectionConverter : a complete collection with different mapping style
(there 2 implementation but you can defined your own)

Some refactoring is required here. Only CollectionConverter is interface
based (until now).

2. AbstarctAtomicTypeConverter should be AbstractAtomicTypeConverter


?

4. the methods on the AtomicConverter and the converter concept and
> plugability are contradictory. The atomic converter specifies through
> the getJavaTypes what classes it should be used for the
> getJcrValueFromJavaObject specifies that " The mapping framework
> ensures, that only objects of the types returned by getJavaTypes are
> forwarded to this method."
> This means in short that the converters can't be used for other types
> other then the ones they have been design for.
> For example if I want to use the Date converter on an object that has
> the same contract, even though I am register it manually it will not
> work.
>
The converter should do the conversion and that's it - it's the
> framework job to do the rest especially if it forces the developer to
> supply the map of converters. Basically you have to write code in two
> parts to do the same thing.


getJavaTypes can be dropped, it is not used now.
I don't understand you, the converter makes conversions and that's all.

Christophe

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message