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 16:42:31 GMT
#: 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.

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