From graffito-dev-return-900-apmail-incubator-graffito-dev-archive=www.apache.org@incubator.apache.org Mon Jan 16 20:16:33 2006 Return-Path: Delivered-To: apmail-incubator-graffito-dev-archive@www.apache.org Received: (qmail 19953 invoked from network); 16 Jan 2006 20:16:28 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 16 Jan 2006 20:16:28 -0000 Received: (qmail 91797 invoked by uid 500); 16 Jan 2006 20:16:25 -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 91708 invoked by uid 99); 16 Jan 2006 20:16:24 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Jan 2006 12:16:24 -0800 X-ASF-Spam-Status: No, hits=1.4 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: 193.19.192.5 is neither permitted nor denied by domain of the.mindstorm.mailinglist@gmail.com) Received: from [193.19.192.5] (HELO mail.evolva.ro) (193.19.192.5) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Jan 2006 12:15:30 -0800 Received: (qmail 30395 invoked by uid 89); 16 Jan 2006 20:15:06 -0000 Received: from unknown (HELO ?192.168.62.51?) (alexandru.popescu@evolva.ro@86.55.40.139) by mail.evolva.ro with AES256-SHA encrypted SMTP; 16 Jan 2006 20:15:06 -0000 Message-ID: <43CBFEA7.80708@gmail.com> Date: Mon, 16 Jan 2006 22:14:31 +0200 From: Alexandru Popescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051201 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: graffito-dev@incubator.apache.org Subject: Re: [mapping] mapping enhancement supporting GRFT54 References: <43C71319.4040904@gmail.com> <3b728ee90601130120x56ac0927xc5242b4bd98039bf@mail.gmail.com> <43C866F4.50604@gmail.com> <3b728ee90601160725i4ab36d0dvb233e4ec426cadbf@mail.gmail.com> <43CBCCF7.50602@gmail.com> <3b728ee90601161148u13655b04i82c0d0c48204d319@mail.gmail.com> In-Reply-To: <3b728ee90601161148u13655b04i82c0d0c48204d319@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N #: Christophe Lombart changed the world a bit at a time by saying (astral= date: 1/16/2006 9:48 PM) :# > On 1/16/06, Alexandru Popescu wro= te: >> #: Christophe Lombart changed the world a bit at a time by saying (ast= ral date: 1/16/2006 5:25 PM) :# >> > Concerning issue http://issues.apache.org/jira/browse/GRFT-54, >> > Why do you think about the following mapping : >> > >> > >> > >> > >> > >> > > > jcrName=3D"jcr:encodiging" .../> >> > >> > .... >> > >> > >> > >> > the "subnode-descriptor" is there to create a new subnode called >> > "jcr-content" which will contains some object attributes like >> > mimeType, encoding, ... >> > >> > Anyway, I like the "converter" idea. At least, it quite easy to >> > implement it for the fd. >> > Converters for cd already exists but they need to be review. But now= , >> > we have to think about how to use the converters for the bd. >> > >> > (I don't speak now on inheritance, we can start this discussion late= r). >> > >> >> The proposal you are making is quite nice for this particular example.= But I cannot say how >> extensible it is (by looking at it I would say that it is pretty much = the bean-descriptor). I would >> like that before introducing more descriptors to be sure that a new on= e will be able to fill in a >> whole range of solutions and not just a particular one. The same appli= es to the existing ones. >=20 > ok - can we create a new jira issues which will contain all use cases. > It is quite difficult to remember all possibilities. >=20 > Thanks >=20 > Not sure what you are asking :-(. Is your question about creating a JIRA = issue for each of the=20 suggested improvements? If yes, than I would say that I would prefere hav= ing it in the ML than=20 directly on JIRA, and upon concluding adding a JIRA with only the conclus= ion. But if you think JIRA=20 is better to handle this discussion than go ahead and open the necessary = enhancement requests. cheers, =2E/alex -- =2Ew( the_mindstorm )p. >> >> ./alex >> -- >> .w( the_mindstorm )p. >> >> > >> > On 1/14/06, Alexandru Popescu = wrote: >> >> #: Christophe Lombart changed the world a bit at a time by saying (= astral date: 1/13/2006 11:20 AM) :# >> >> > On 1/13/06, Alexandru Popescu wrote: >> >> > >> >> >> considering the GRFT54 example, you will write: >> >> >> >> >> >> > >> >> converterClass=3D"NtFileConverter" /> >> >> >> >> >> >> and NtFileConverter will be responsible for creating the nt:file= node structure. Same mechanism will >> >> >> work for fetching. >> >> >> >> >> > >> >> > I like this idea but how set the mapping rules for each attribute= s ? >> >> > I expect the field-descriptor, bean-descriptor & collection-descr= iptor >> >> > are still necessary if we uses the convertClass. >> >> > >> >> >> >> This is a very good question to which unfortunately i don't have a = good answer. While a predefined >> >> converter knows how to deal with a limitted set of properties/subno= des, on the other side (e.g. on >> >> objects world) those properties may come from really complex expres= sions. >> >> There are a few possible approaches to solving this, but for the mo= ment none of them satisfies me: >> >> - have the object implement an interface which responds to the need= s of the converter >> >> (may be considered bad because it ties the object to the ojcrm tool= ) >> >> - have the description provided through the same mechanisms of fd, = bd or cd >> >> (may be considered bad because the mapping becomes complex, and cha= nges in some way the semantics of >> >> fd, bd and cd) >> >> - create/reuse a object graph navigation language >> >> (may be considered bad because the user should learn a new/the user= should use a new `language=B4) >> >> - have the converter provide extension points so that in special ca= ses an user may extend it to >> >> extract the values/populate the values >> >> >> >> Example: >> >> 1/ in the simplest case where the object provides accessors to the = object properties according to >> >> the needs of the converter than you don't need to detail the mappin= g (the node property paths and >> >> subnodes paths maps directly to object properties) >> >> 2/ in more complex cases where the object needs special manipulatio= n in order to provide/to write >> >> object properties, than the user should extend the converter and pr= ovide access to those properties >> >> >> >> what do you think? >> >> >> >> ./alex >> >> -- >> >> .w( the_mindstorm )p. >> >> >> >>