Hi! As I said this will be a multi-episode email, cause so far my research is limitted. Please see my comments inlined.
On 1/12/06, Christophe Lombart <[EMAIL PROTECTED]> wrote: > Hi Alex, > > I'm also interesting by this kind of features. Here are my comments. > On 1/12/06, Alexandru Popescu <[EMAIL PROTECTED]> wrote: > > Hi! > > > > I've started thinking about possible extension of the current > > supported mapping strategies. The directions I am investigating right > > now are including: > > - component mapping > > ok what about the following issue : > http://issues.apache.org/jira/browse/GRFT-54. > Looks interesting. Must think of it. At a first glance, the approach I am envisioning is to allow registration of custom node type persisters. So that when an object with a corresponding such node type is met during the object graph persistence we can delegate to its own persister. Sure for, some special node types we can provide out of the box persister. (as in your example: nt:file). > > - relations > Can you give more info. What kind of relations ? Are you speaking > about object associations ? > Usually in objectual world we can talk about object associations: one-to-one, one-to-many, many-to-one, many-to-many, unidirectional associations, bidirectional associations. That's what will be here. > > - inheritance > > ... and interface. It should be nice to make query based on interface > and of course ancestor class. > Interface and ancestor classes are part of the inheritance, so yes I hope to address these soon. > > > - spreaded > > Can you give more info ? What I called spreaded objects is a concept that would mean persist an object in various places (as opposed to persist an object to this subtree nodes). Still I need to figure out if such a scenario makes any sense. Furthermore, this is something that is last on my list, so ... ./alex -- .w( the_mindstorm )p. > > > > So far (and indeed the easiest one) are the component mappings: they > > allow mapping the properties of a child object to the properties of > > the current working node. In the JCR world, a very good example of > > this are the mixins. Introducing a mixin to a node may add a set of > > properties that the user can manipulate with the help of a single > > entity. > > Such an entity doesn't have any restrictions upon it (no path > > required, as it doesn't live by itself, no limitation in children, > > anything). > > > > Please let me know what do you think about this. > > > > In the future episodes I will try to address the remaining areas. > > > > cheers, > > > > ./alex > > -- > > .w( the_mindstorm )p. > > > > > -- > Best regards, > > Christophe >
