From graffito-dev-return-984-apmail-incubator-graffito-dev-archive=www.apache.org@incubator.apache.org Wed Feb 08 22:02:31 2006 Return-Path: Delivered-To: apmail-incubator-graffito-dev-archive@www.apache.org Received: (qmail 43827 invoked from network); 8 Feb 2006 22:02:20 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 8 Feb 2006 22:02:20 -0000 Received: (qmail 42040 invoked by uid 500); 8 Feb 2006 22:02:14 -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 42028 invoked by uid 99); 8 Feb 2006 22:02:14 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 08 Feb 2006 14:02:13 -0800 X-ASF-Spam-Status: No, hits=1.3 required=10.0 tests=RCVD_IN_BL_SPAMCOP_NET,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of christophe.lombart@gmail.com designates 66.249.92.205 as permitted sender) Received: from [66.249.92.205] (HELO uproxy.gmail.com) (66.249.92.205) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 08 Feb 2006 14:02:13 -0800 Received: by uproxy.gmail.com with SMTP id s2so10695uge for ; Wed, 08 Feb 2006 14:01:50 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=thyVv0RZbIaMgWY/qNoMqHSBhDXBDsYp4ZZYZ7uQFzanOa/qts5sCPfnafGKaLZiJ+PRgR47jP9N0qdlD+a2QoUmDkSvjIC9dSDJ4XHycqGDYoZX/s23w4Ddfi0Xw0MLXvJcLepKSUDiFzu4/oHzKZt77l/gl/eVqKt/Dqs5OHk= Received: by 10.49.80.10 with SMTP id h10mr2141334nfl; Wed, 08 Feb 2006 14:01:50 -0800 (PST) Received: by 10.48.255.8 with HTTP; Wed, 8 Feb 2006 14:01:49 -0800 (PST) Message-ID: <3b728ee90602081401h156ecb98s2b2829d7a3c24d29@mail.gmail.com> Date: Wed, 8 Feb 2006 23:01:49 +0100 From: Christophe Lombart To: graffito-dev@incubator.apache.org Subject: Re: JCR mapping package naming In-Reply-To: <3b728ee90602081357u1b3a6af3qd9e32d4bcdcb11d3@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <43EA320F.2070800@gmail.com> <3b728ee90602081155o42192d6ex973e30cc69e62066@mail.gmail.com> <43EA5F21.4010206@gmail.com> <3b728ee90602081357u1b3a6af3qd9e32d4bcdcb11d3@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N I modified the Graffito site and add information on the JCR mapping stuff. I cannot update/commit because my laptop battery is break down and cannot restart my laptop :-( Hope to solve this issue ASAP and publish the new site. On 2/8/06, Christophe Lombart wrote: > On 2/8/06, Alexandru Popescu wrote: > > > promoting it would be: "why is it portals?" > Because the targeted community is mainly the ASF portal :-) > We can try to write an article on the OCM concept and use graffito as > an example. than, we can promote OCM on the Jackrabbit list and other > areas. > > > > > I am reviewing right now the collection converters and fixing the excep= tion handling. After this > > step, and some small refactorings in the filters, I will be ready for i= nterfaces/inheritance. Once > > those are done, or at least addressed we should start promoting it. > > > I'm interesting to add new attributes in collection-descriptor (cd) > and bean-descriptor (bd) (inspired from OJB) : > 1/ lazy loading : load the bean attribute or the collection attribute > when the getter method is called - not when the main object is > retrieved. > 2/auto retrieve . this is an alternative to the the lazy loading. If > false, the bean attribute (or the collection attribute) is not > retrieved. The developer can use a new method defined on the PM to > load the object. I prefer the lazy loading solution but sometime it > can be usefull to control when loading the attribute. > 3/ auto-update: if true : when the main object is updated, the > bean/collection attribute is updated.If false, the attribute is not > updated. There a lot of case when the graph is loaded (eg. one folder > & its content) and only updates are done on the main object. > > Those attributes should gives the possiblity to support deep JCR > structures without loosing good performances. > > What do you think ? > > I'm also thinking about the inheritance/interface support : > 1/ Inheritance : the class-descriptor can contain a new element like this= : > > > ..... > > > > > > > > > > > A query can be done like this : > > Filter filter =3D queryManager.createFilter(CmsObjectImpl.class); > filter.setScope("/test/node1//"); > Query query =3D queryManager.createQuery(filter); > Collection result =3D persistenceManager.getObjects(query); > > =3D> if the JCR query is build with the ancestor node type, it should > work with no many changes in the current code.This solution doesn't > work if the nt:unstructured type is used. > > This is just an idea and it needs to be review in more details - what > do you think ? > > 2/ Interface : I don't understand why mixin node types should be use. > Java interface have not some attributes. So, I don't see how it can be > set into the JCR node type hierarchy. > I think we can also reuse the extent-class element but more > modification in the current code is required. Still thinking about > that. > > -- > Best regards, > > Christophe > -- Best regards, Christophe