incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christophe Lombart <christophe.lomb...@gmail.com>
Subject Re: [jira] Updated: (GRFT-34) An initial code base for the mapping project.
Date Fri, 22 Jul 2005 07:44:57 GMT
2005/7/19, Sandro Böhme <sandro.boehme@gmx.de>:
> 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.
> 

+1 it simplify the mapping config file. We made a refactoring if
someone want to defined getter/setter methods.
> 
> 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.
> 

+1 but subitem can be replace like this :
<subitemMapping propertyName="description"  parameterType="long"      
                    jcrPropertyDefinition name="graffito:parentId" />


> 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.
> 
> >

Maybe a small example can help to understand. What will be the mapping
file for this kind of situation : folder contains some documents.

Normally, we should have :
folder1
    doc1






> >
> >>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