From graffito-dev-return-352-apmail-incubator-graffito-dev-archive=www.apache.org@incubator.apache.org Tue Jul 19 21:36:43 2005 Return-Path: Delivered-To: apmail-incubator-graffito-dev-archive@www.apache.org Received: (qmail 28693 invoked from network); 19 Jul 2005 21:36:43 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 19 Jul 2005 21:36:43 -0000 Received: (qmail 79554 invoked by uid 500); 19 Jul 2005 21:36:42 -0000 Mailing-List: contact graffito-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: graffito-dev@incubator.apache.org Delivered-To: mailing list graffito-dev@incubator.apache.org Received: (qmail 79541 invoked by uid 99); 19 Jul 2005 21:36:42 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 19 Jul 2005 14:36:42 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of sandro.boehme@gmx.de designates 213.165.64.20 as permitted sender) Received: from [213.165.64.20] (HELO mail.gmx.net) (213.165.64.20) by apache.org (qpsmtpd/0.29) with SMTP; Tue, 19 Jul 2005 14:36:38 -0700 Received: (qmail invoked by alias); 19 Jul 2005 21:36:39 -0000 Received: from p54A3C594.dip.t-dialin.net (EHLO [192.168.2.2]) [84.163.197.148] by mail.gmx.net (mp012) with SMTP; 19 Jul 2005 23:36:39 +0200 X-Authenticated: #1646957 Message-ID: <42DD72FC.6050007@gmx.de> Date: Tue, 19 Jul 2005 23:39:08 +0200 From: =?ISO-8859-1?Q?Sandro_B=F6hme?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: graffito-dev@incubator.apache.org Subject: Re: [jira] Updated: (GRFT-34) An initial code base for the mapping project. References: <1495988945.1120919413871.JavaMail.jira@ajax.apache.org> <42D6E7C2.6050707@gmx.de> <3b728ee905071702125be3202d@mail.gmail.com> In-Reply-To: <3b728ee905071702125be3202d@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Hello, Christophe Lombart wrote: >2005/7/16, Oliver Kiessler : > > >>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...): >> >> >> >> >jcrChildNodeType="graffito:myComplexObject" ... /> >> >> >> >> >> >>.... >> >> >> >> >> > >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 the Java classes nor the node types can lead the structure. This is why I used this structure (simplyfied for easier reading) : 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