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: [jira] Updated: (GRFT-34) An initial code base for the mapping project.
Date Tue, 19 Jul 2005 21:39:08 GMT
Hello,

Christophe Lombart wrote:

>2005/7/16, Oliver Kiessler <oliver.kiessler@gmail.com>:
>  
>
>>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

Mime
View raw message