Hello,
Christophe Lombart wrote:
2005/7/16, Oliver Kiessler <[EMAIL PROTECTED]>:
hi,
first of all thank you for the valuable feedback.
What is the general feeling about this initial version?
Are we heading in the right direction?
I think the initial version is a little too complex. I would prefer a
much simpler initial solution as christophe stated (simplified xml
mapping syntax).
I'd prefer something like this (it's just pseudo xml...):
<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>
Personnaly, I'm +1 with your idea. getter/setter are not necessary. I
prefer to use the bean properties directly. Sandro, when do you want
to use getter/setter instead of properties ?
the getter/setter are in the xml-file to make POJO's "JCR-capable". But
like I said before:
I'am +1 for supporting beans as an additional alternative which would
make the mapping-xml
file less complex for the bean use case.
Please vote if you only want to support Java beans and don't want to
support POJO's.
While working on the mapping I had a very similar xml structure. But I
changed it to the current structure
because I think an easy goal of the project is the mapping in _both_
directions. This additional feature
should not add very much effort but it adds much flexibility and some
use cases. This means neither <se?lp=ende&p=/Mn4k.&search=neither>
the Java classes nor the node types can lead the structure. This is why
I used this structure (simplyfied
for easier reading) :
<xsd:element name="mapping">
<xsd:element ref="classAttributes" minOccurs="0"
maxOccurs="1"/>
<xsd:element ref="nodeTypeAttributes" minOccurs="0"
maxOccurs="1"/>
<xsd:element ref="subitemMapping" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:element>
This is direction neutral and makes sense for people who map a Java
domain model to given node
types and also for people who map node types to a given domain model
(e.g. CMS vendors).
It also adds a Java scope and a JCR scope. So everybody knows which
attributes belong to the JCR
and which belong to Java. E.g. to know at the first sight if "property"
belongs to the JCR part or to the
Java part of the mapping.
As I think it wasn't very clear before, please vote, if you want to
support a mapping in both directions.
I agree to skip the "package" attribute and use full qualified class names.
java class => jcr node
java class property (primitive and String) => jcr property
java class complex property (bean) => jcr child node with jcr properties
(1) or a reference using a JCR ID. Eg. a Document can have a
ParentFolder property but this property is not a Document child node.
Is it make sense for you ?
java class array property (primitive and String) => jcr multivalued property
java class array property (bean) => jcr child node with n jcr child nodes
Same idea as (1)
java class collection property (bean) => jcr child node with n jcr child nodes
Same idea as (1)
In my point of view, an association tag is needed to make references
to a JCR node somewhere.
At the moment collections and references are not yet supported in the
initial version.
I'am not sure if I understand it completely. But at the moment the
mapping file does
not specify objects and nodes (instances) it only specifies node types
and classes. This is why I think
we cannot directly reference nodes/objects with concrete ID's in the
mapping file. Instead we could
specify only the source and the destination of the reference in the
mapping file and let the
persistence manager handle the concrete references (UUID's, Path's,
Object Id's) when it
stores/load objects in/from the repository.
I think we should go for an "convention over configuration" approach.
Why specify that a java class property of type String maps to a jcr
string property (we can use reflection to find out property
types....)? You know what I mean? One should only add this information
if it's break the convention.
If nobody completely disagrees with it, I would try to get a solution
for the JAXB
issue on the basis of a general consensus.
-1 for JAXB
+1 for Commons-beanutils or XmlBeans (they have just released a new version 2.0)
Is it necessary to use xmlBeans ? Digester is not sufficiant. it is
quite simple to use.
I don't speak for the _RI_ of JAXB but it was really helpful to change
the mapping schema and let the
according beans are generated automatically. This definetly saved me
many hours because
I had 3 or 4 major structural changes and of course many small ones.
I wouldn't vote +1 for a JAXB implementation in general but I definitely
vote +1 for a stable library
supporting XML binding.
What I don't like about JAXB 1.0 is that one cannot add interface
statements to the generated
beans. This would make the persistance strategy of the mapping model
more exchangeable and maybe
it would make some adapter classes easier.
Regards,
Sandro
