incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christophe Lombart <>
Subject Re: [jcr-mapping] converter design
Date Tue, 04 Oct 2005 13:47:06 GMT
On 10/4/05, Costin Leau <> 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.


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