incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexandru Popescu <the.mindstorm.mailingl...@gmail.com>
Subject Re: [mapping] mapping enhancement supporting GRFT54
Date Mon, 16 Jan 2006 21:48:00 GMT
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.

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.

./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
> 



Mime
View raw message