You are viewing a plain text version of this content. The canonical link for it is here.
Posted to graffito-dev@incubator.apache.org by Alexandru Popescu <th...@gmail.com> on 2006/01/13 02:40:25 UTC
[mapping] mapping enhancement supporting GRFT54
Hi!
I've been thinking about the enhancement in GRFT54 [1]. Currently this is possible, using imbricated
beans. However, the intention would be to allow easier mappings for such examples.
At this moment, a bean is always considered to map to a child node (a one-to-one mapping). As GRFT54
is showing, this approach is not covering all possibilites. I guess a greater generality can be
reached by allowing a bean to specify its persister class.
The interface that a persister class should implement would be very simple:
[code]
/**
* @param jcrName mapping specified jcrName or fieldName
*/
insert(Session, Node parentNode, String jcrName, Object beanObject);
update(Session, Node parentNode, String jcrName, Object beanObject);
remove(Session, Node parentNode, String jcrName, Object beanObject);
Object load(Session, Node parentNode, String jcrName)
[/code]
For making things even simplier in some scenario, we can provide such specific persister
implementations for a few node types defined in the JSR170 (a good example would be nt:file).
Full example:
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 would like to hear you opinion, before starting to work on this idea.
[1] http://issues.apache.org/jira/browse/GRFT-54
cheers,
./alex
--
.w( the_mindstorm )p.
Re: [mapping] mapping enhancement supporting GRFT54
Posted by Alexandru Popescu <th...@gmail.com>.
#: Christophe Lombart changed the world a bit at a time by saying (astral date: 1/17/2006 12:12 AM) :#
> On 1/16/06, Alexandru Popescu <th...@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 ?
>
As described previously a component is an entity that cannot live by its own, but has a logical
meaning. Take for example an Address. It may live alone, but doesn't make much sense in some
systems. Once associated with an User it starts making sense. Now, as in RDBMS you can choose the
persist this as a record in a separate table with a 1-1 relation, or you may choose to persist
Address field along with the User.
Now, returning to JCR, the component is fitting perfectly the mixin notion. A mixin cannot live by
its own in the repository. It is associated with some node. It's properties are added to the set of
original node.
hope this clarifies it,
./alex
--
.w( the_mindstorm )p.
>> ./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 <th...@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 <th...@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 <th...@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 <th...@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.
>> >> >> >>
>> >> >> >>
Re: [mapping] mapping enhancement supporting GRFT54
Posted by Christophe Lombart <ch...@gmail.com>.
On 1/16/06, Alexandru Popescu <th...@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 <th...@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 <th...@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 <th...@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 <th...@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
Re: [mapping] mapping enhancement supporting GRFT54
Posted by Alexandru Popescu <th...@gmail.com>.
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 <th...@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 <th...@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 <th...@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 <th...@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
>
Re: [mapping] mapping enhancement supporting GRFT54
Posted by Christophe Lombart <ch...@gmail.com>.
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 <th...@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 <th...@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 <th...@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 <th...@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
Re: [mapping] mapping enhancement supporting GRFT54
Posted by Alexandru Popescu <th...@gmail.com>.
#: 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 <th...@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 <th...@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 <th...@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.
>> >>
>> >>
Re: [mapping] mapping enhancement supporting GRFT54
Posted by Christophe Lombart <ch...@gmail.com>.
On 1/16/06, Alexandru Popescu <th...@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
>
> ./alex
> --
> .w( the_mindstorm )p.
>
> >
> > On 1/14/06, Alexandru Popescu <th...@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 <th...@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
> >
>
>
>
--
Best regards,
Christophe
Re: [mapping] mapping enhancement supporting GRFT54
Posted by Alexandru Popescu <th...@gmail.com>.
#: 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 <th...@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 <th...@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
>
Re: [mapping] mapping enhancement supporting GRFT54
Posted by Christophe Lombart <ch...@gmail.com>.
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).
On 1/14/06, Alexandru Popescu <th...@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 <th...@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
Re: [mapping] mapping enhancement supporting GRFT54
Posted by Alexandru Popescu <th...@gmail.com>.
#: 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 <th...@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
>
Re: [mapping] mapping enhancement supporting GRFT54
Posted by Christophe Lombart <ch...@gmail.com>.
On 1/13/06, Alexandru Popescu <th...@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.
--
Best regards,
Christophe