incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexandru Popescu <>
Subject Re: [mapping] mapping enhancement supporting GRFT54
Date Sat, 14 Jan 2006 02:50:28 GMT
#: 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 <> 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
- 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
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

1/ in the simplest case where the object provides accessors to the object properties according
the needs of the converter than you don't need to detail the mapping (the node property paths
subnodes paths maps directly to object properties)
2/ in more complex cases where the object needs special manipulation in order to provide/to
object properties, than the user should extend the converter and provide access to those properties

what do you think?

.w( the_mindstorm )p.

> --
> Best regards,
> Christophe

View raw message