incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sandro Böhme <sandro.boe...@gmx.de>
Subject Re: [jcr-mapping] mapping strategy: mapping in both directions
Date Sun, 31 Jul 2005 22:23:21 GMT
Oliver Kiessler wrote:

>>after reviewing the thread I think we have a general consensus about the
>>following mapping strategy
>>(please correct me if I'm wrong):
>>
>>Java class ==> JCR nodetype
>>Bean property ==> JCR child node definition
>>
>>Please vote or discuss this open aspect:
>>++ Do we need a mapping in both directions? ++
>>Not considering the concrete layout of the xml file we have a
>>+1 from me and a
>>+1 from Christophe
>>    
>>
>
>0 (I am neutral about this one, please go ahead if you think this matters)
>
>
>  
>
In my opinion the difference is in the structure of the mapping xml file.
If I would want to map classes to node types, I would let the classes
lead the structure like you said in the other thread:
<class name="my.app.Test" jcrNodeType="graffito:Test">
   <property name="myStringProperty" />
   <property name="myComplexObject"
jcrChildNodeType="graffito:myComplexObject" ... />
</class>

<class name="my.app.MyComplexObject" 
jcrNodeType="graffito:myComplexObject">
   <property name="myIntValue" jcrPropertyType="jcr:long" ... />

....

</class>

If we map in both directions, I think we would need something like 
Christophe said:

<subitemMapping propertyName="description"  parameterType="long"

jcrPropertyDefinition name="graffito:parentId" />

At the moment I register node types out of a Java classes with the
node type registration component.
If we map in both directions, maybe it makes sense later, to also
generate Java classes out of node types.
E.g. a jcrmapping.nt.File classes which inherits from the
jcrmapping.nt.HierarchyNode class which in turn inherits from
the jcrmapping.nt.Base class and of course with all custom 
node types generated in the same manner.

Regards,
Sandro




Mime
View raw message