#: 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
