incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christophe Lombart <christophe.lomb...@gmail.com>
Subject Re: [mapping] mapping enhancement supporting GRFT54
Date Mon, 16 Jan 2006 19:48:23 GMT
On 1/16/06, Alexandru Popescu <the.mindstorm.mailinglist@gmail.com> wrote:
> #: Christophe Lombart changed the world a bit at a time by saying (astral 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  :
> >
> > <class-descriptor className="xxx.File" jcrNodeType="nt:file" >
> >         <field-descriptor fieldName="path" path="true" />
> >         <subnode-descriptor   jcrName="jcr:content" ... >
> >             <field-descriptor fieldName="mimeType" jcrName="jcr:mimeType" ...
/>
> >             <field-descriptor fieldName="encoding"
> > jcrName="jcr:encodiging" .../>
> >             <field-descriptor fieldName="data" jcrName="jcr:data" ... />
> >             ....
> >         </subnode-descriptor>
> > </class-desciptor>
> >
> > 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 later).
> >
>
> 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 one will be able
to fill in a
> whole range of solutions and not just a particular one. The same applies to the existing
ones.

ok - can we create a new jira issues which will contain all use cases.
It is quite difficult to remember all possibilities.

Thanks


>
> ./alex
> --
> .w( the_mindstorm )p.
>
> >
> > On 1/14/06, Alexandru Popescu <the.mindstorm.mailinglist@gmail.com> 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 <the.mindstorm.mailinglist@gmail.com>
wrote:
> >> >
> >> >> considering the GRFT54 example, you will write:
> >> >>
> >> >> <bean-descriptor fieldName="file"
> >> >>                  converterClass="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 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 answer.
While a predefined
> >> converter knows how to deal with a limitted set of properties/subnodes, on the
other side (e.g. on
> >> objects world) those properties may come from really complex expressions.
> >> There are a few possible approaches to solving this, but for the moment none
of them satisfies me:
> >> - have the object implement an interface which responds to the needs 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 changes 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Ā“)
> >> - have the converter provide extension points so that in special cases 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 mapping (the node
property paths and
> >> subnodes paths maps directly to object properties)
> >> 2/ in more complex cases where the object needs special manipulation in order
to provide/to write
> >> object properties, than the user should extend the converter and provide access
to those properties
> >>
> >> what do you think?
> >>
> >> ./alex
> >> --
> >> .w( the_mindstorm )p.
> >>
> >>
> >>
> >>
> >> > --
> >> > Best regards,
> >> >
> >> > Christophe
> >> >
> >>
> >>
> >>
> >>
> >
> >
> > --
> > Best regards,
> >
> > Christophe
> >
>
>
>


--
Best regards,

Christophe

Mime
View raw message