Sandro Böhme wrote:
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
If we would add an "automatic generation" flag to either the nodetype or
the class side of the
mapping, we could generate the nodetype or the Java class with all
information specified in
the mapping file.
