[jcr-mapping] converter design

[Costin Leau <co...@gmail.com>]

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
2. AbstarctAtomicTypeConverter should be AbstractAtomicTypeConverter
3. getJavaXXX should be renamed to getXXX - the Java part is not
needed
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.
  

-- 
Best regards,
 Costin                          mailto:costin.leau@gmail.com

Re: [jcr-mapping] converter design

[Christophe Lombart <ch...@gmail.com>]

On 10/4/05, Costin Leau <co...@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