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 22:12:49 GMT
On 1/16/06, Alexandru Popescu <the.mindstorm.mailinglist@gmail.com> wrote:
> Halo!
>
> My list was:
>
> 1/ components
> 2/ custom persistence (GRFT-54 like)
> 3/ relations
> 4/ inheritance
> 5/ spread (if it applies, I am not sure yet).
>
> I am not sure about the connection with collection converters? Are you asking if the
interface of
> collection converters fits the interface i was describing for GRFT-54? Well they are
in the same
> direction, but there are big differences.

of course, it is just to know if you already review them.
>
> My goal is to have the 1st 2 defined by the end of this week, so that during the weekned
I can
> already start working on them.
>
> My current vision is to redesign the bean-descriptor to fit all 3 scenarios: components,
custom
> persistence and current scenario. In big lines they are very related, the only difference
between
> them being the node under which they are persisted:
>
> components: directly in the current node
> GRFT-54: somewhere on a node in a subtree rooted in the current node
> current bd: as a direct child node in the current node.
>
> If all these can be leveled in the bd definition than I guess we pretty much covered
a lot.
>

Can you give me an example for "component" ? Is it a set of node
properties map to a bean  ?

> ./alex
> --
> .w( the_mindstorm )p.
>
> #: Christophe Lombart changed the world a bit at a time by saying (astral date: 1/16/2006
11:01 PM) :#
> > Well, honnestly I don't remember the complete discussion.
> >
> > So what are all the improvements you are looking for ?
> > 1. the GRFT-54 support - Are there other similar improvements ?
> > 2. inheritance
> > 3. Spread (?)
> > 4. ??
> >
> > What about the converter, did you check the collection converter ? is
> > it fit your needs ?
> >
> >
> >
> >
> > 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 9:48 PM) :#
> >> > 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
> >> >
> >> >
> >>
> >> Not sure what you are asking :-(. Is your question about creating a JIRA issue
for each of the
> >> suggested improvements? If yes, than I would say that I would prefere having
it in the ML than
> >> directly on JIRA, and upon concluding adding a JIRA with only the conclusion.
But if you think JIRA
> >> is better to handle this discussion than go ahead and open the necessary enhancement
requests.
> >>
> >> cheers,
> >>
> >> ./alex
> >> --
> >> .w( the_mindstorm )p.
> >>
> >>
> >> >>
> >> >> ./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

Mime
View raw message