incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Leau <>
Subject Re[2]: [jcr-mapping] converter design
Date Tue, 04 Oct 2005 14:07:59 GMT
Hello Christophe,

Tuesday, October 4, 2005, 4:47:06 PM, you wrote:




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

absTARCT should be absTRACT.




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
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. 
Yes but the java types method add extra functionality like I said and you also should not
the converter problem.






Best regards,
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message