From graffito-dev-return-896-apmail-incubator-graffito-dev-archive=www.apache.org@incubator.apache.org Sat Jan 14 02:51:37 2006 Return-Path: Delivered-To: apmail-incubator-graffito-dev-archive@www.apache.org Received: (qmail 68999 invoked from network); 14 Jan 2006 02:51:37 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 14 Jan 2006 02:51:37 -0000 Received: (qmail 73681 invoked by uid 500); 14 Jan 2006 02:51:36 -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 73666 invoked by uid 99); 14 Jan 2006 02:51:35 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 13 Jan 2006 18:51:35 -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; Fri, 13 Jan 2006 18:51:34 -0800 Received: (qmail 43615 invoked by uid 89); 14 Jan 2006 02:51:11 -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; 14 Jan 2006 02:51:11 -0000 Message-ID: <43C866F4.50604@gmail.com> Date: Sat, 14 Jan 2006 04:50:28 +0200 From: Alexandru Popescu User-Agent: Thunderbird 1.5 (Windows/20051201) 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> In-Reply-To: <3b728ee90601130120x56ac0927xc5242b4bd98039bf@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/13/2006 11:20 AM) :# > On 1/13/06, Alexandru Popescu wro= te: >=20 >> 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. >> >=20 > I like this idea but how set the mapping rules for each attributes ? > I expect the field-descriptor, bean-descriptor & collection-descriptor > are still necessary if we uses the convertClass. > This is a very good question to which unfortunately i don't have a good a= nswer. While a predefined=20 converter knows how to deal with a limitted set of properties/subnodes, o= n the other side (e.g. on=20 objects world) those properties may come from really complex expressions.= There are a few possible approaches to solving this, but for the moment n= one of them satisfies me: - have the object implement an interface which responds to the needs of t= he 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 changes i= n some way the semantics of=20 fd, bd and cd) - create/reuse a object graph navigation language (may be considered bad because the user should learn a new/the user shoul= d use a new `language=B4) - have the converter provide extension points so that in special cases an= user may extend it to=20 extract the values/populate the values Example: 1/ in the simplest case where the object provides accessors to the object= properties according to=20 the needs of the converter than you don't need to detail the mapping (the= node property paths and=20 subnodes paths maps directly to object properties) 2/ in more complex cases where the object needs special manipulation in o= rder to provide/to write=20 object properties, than the user should extend the converter and provide = access to those properties what do you think? =2E/alex -- =2Ew( the_mindstorm )p. > -- > Best regards, >=20 > Christophe >=20