From graffito-dev-return-340-apmail-incubator-graffito-dev-archive=www.apache.org@incubator.apache.org Thu Jul 14 07:58:03 2005 Return-Path: Delivered-To: apmail-incubator-graffito-dev-archive@www.apache.org Received: (qmail 43143 invoked from network); 14 Jul 2005 07:58:03 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 14 Jul 2005 07:58:03 -0000 Received: (qmail 23041 invoked by uid 500); 14 Jul 2005 07:58:00 -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 22996 invoked by uid 99); 14 Jul 2005 07:57:59 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 14 Jul 2005 00:57:59 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=RCVD_BY_IP,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of christophe.lombart@gmail.com designates 64.233.182.204 as permitted sender) Received: from [64.233.182.204] (HELO nproxy.gmail.com) (64.233.182.204) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 14 Jul 2005 00:57:56 -0700 Received: by nproxy.gmail.com with SMTP id i2so83662nfe for ; Thu, 14 Jul 2005 00:57:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=EpVk1IpEZHkWWVWOWBRH507pRpmOGwf2U3Kj4rSLCmeQjUQ5LTy8vC8yieJHEY8gbS/8p9MwgBUZu+QeM4p6RLnzqq9uK7x1RiBT6DUtZlC059ZZRbddnbliCHl1wt6PpHEayqg/85u7+TkNFST1OOB9OL+II/R/33pcwIyvmRA= Received: by 10.48.249.6 with SMTP id w6mr57773nfh; Thu, 14 Jul 2005 00:57:55 -0700 (PDT) Received: by 10.48.249.5 with HTTP; Thu, 14 Jul 2005 00:57:55 -0700 (PDT) Message-ID: <3b728ee9050714005740871494@mail.gmail.com> Date: Thu, 14 Jul 2005 09:57:55 +0200 From: Christophe Lombart Reply-To: Christophe Lombart To: graffito-dev@incubator.apache.org Subject: Re: [jira] Updated: (GRFT-34) An initial code base for the mapping project. In-Reply-To: <42D593CF.1030602@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <872368540.1120919410392.JavaMail.jira@ajax.apache.org> <1495988945.1120919413871.JavaMail.jira@ajax.apache.org> <3b728ee905071215336ba55b31@mail.gmail.com> <42D593CF.1030602@gmx.de> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Hi Sandro, Here is my comments :=20 2005/7/14, Sandro B=F6hme : > If your converter would create custom node type structures, than the > user would require to > register this custom node type structure by themself. The reason is, if > the mapping > can be defined absolutely free by the user, you cannot create a reusable > registration > component for the user. > But if you mean something like a proxy to map an object to already > registered node types, > it should be possible to use the AtomicTypeConverter. But can you please > describe > a specific mapping scenario as an example? Maybe it is a use case I have > not yet considered. >=20 There are 2 reasons :=20 1. The first reason is to be sure to support complex cases and at least map the object by hand. If something is missing in our mapping tools, a specific converter can be used until the solution is implemented into the framwork. Maybe as you suggest, the AtomicTypeConverter can solve this issue. Can you give us a concret usage of AtomicType Converter ? A small unit test should help me to understand. 2. Well, I would like to use this framework for CMS server which are not yet supported JCR. JCR is quite young and than it is possible to use a CMS server based on a propriatary API. So, Thoses converter classes can be a solution. This is not my top first requirements. We can imagine to refactor later (if needed). In fact, it depends on the JCR success :-). If JCR becomes more and more popular, my proposal is not important. So, forget my comment if the AtomicTypeConverter can manage complex mapping= . >=20 > >2. I found JAXB a little bit heavy. There are too many generated > >classes. I think it should be possible to find a easier solution based > >on BeanUtil and/or Digester and/or XmlBean. BeanUtil is quite > >powerfull and simple to use. I think it is a good tools for a > >persistence framework. > > > > > Please see my email to Oliver regarding this. > At the moment I cannot find a big difference of to my implementation > except the mapping of the > JCR property. I have seen the JCR property like a Java bean property > which is exposed by > the getter and setter methods of the bean class. If I get your point, > you see a JCR property > as a local variable of a Java class. This also makes sense in my > opinion. I think we should > have both mappings. WDYT? I'm not sure if it is possible to get the > state of private local > variables. > BTW: The initial codebase only contains the creation of nodes but not > yet the creation of objects. >=20 Correct, After reviewing in more details, it is almost the same. I just want to use the common apache tools to promote them :-). It is not very good if some ASF portal projects are using some tools and Graffito others. I would like to use the same in order to maximize the product integration. Please, when you want to use a specific tools, make a proposal (and vote) on the dev mailing list. Now, I'm reviewing the mapping file (JavaToJcrMapping.xml). Here is my comments : * Why it is necessary to delcare the read/write methods ? Why not to something like that : =09 If you have the bean property, it is possible to find the get/set methods. By this way, it is less verbose. Commons BeanUtil can help to set/get the values. * Maybe, we have to defined some classes as Abstract and reuse their mapping setting into their descendants. Eg. CmsObject is the ancestor of Folders & Documents. it is usefull to defined the mapping for CmsObject properties and than reuse it in the mapping for Folder and Document. This should be an optional feature but I think an interesting one. * We have to defined some associations tags or another solution to solve the following issue : Eg. In the mapping for CmsObject, there is a subitemMapping entry for the ParentFolder. ParentFolder is not a subitem of CmsObject. In real application, Folder contains a collection of CmsObjects. So, an association tag (with a ID/path) can be interesting for such case. If a javabean propoperty is an object, it can be a subitem or a reference to another object somewhere in the repository (parent node, ...) Regards, Christophe