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: OCM - Inheritance & Interface
Date Fri, 10 Feb 2006 00:43:40 GMT
#: Alexandru Popescu changed the world a bit at a time by saying (astral date: 2/10/2006 12:57
AM) :#
> #: Christophe Lombart changed the world a bit at a time by saying (astral date: 2/9/2006
10:21 PM) :#
>> Hi all,
>> 
>> Here is some ideas on the inheritance and interface support for our
>> JCR mapping framework. In the first time, I'm focusing mainly on the
>> modification required in the file descriptor.
>> 
>>  :
>> 1/ Inheritance : the class-descriptor can contain a new element
>> (extent-class) like this :
>> 
>> <class-descriptor class="CmsObjectImpl" jcrName="graffio:cmsobject">
>>  .....
>> </class-desciptor>
>> 
>> <class-descriptor class="FolderImpl" jcrName=""graffito:folder >
>>    <extent-class class-ref = "CmsObjectImpl">
>>   ...
>> </class-desciptor>
>> 
>> <class-descriptor class="ContentImpl" jcrName="graffito:content" >
>>    <extent-class class-ref = "CmsObjectImpl">
>>    ....
>> </class-desciptor>
>> 
>> the extent-class is use to make a reference to the "ancestor" class-descriptor.
>> 
>> A query can be done like this :
>> 
>> Filter filter = queryManager.createFilter(CmsObjectImpl.class);
>> filter.setScope("/test/node1//");
>> Query query = queryManager.createQuery(filter);
>> Collection result = persistenceManager.getObjects(query);
>> 
>> the collection result can contain ContentImpl and/or FolderImpl element.
>> If the JCR query is build with the ancestor node type, it should
>> work with no many changes in the current code.This solution doesn't
>> work if the nt:unstructured type is used.
>> 
>> This is just an idea and it needs to be review in more details - what
>> do you think ?
>>
> 
> Considering that the class-descriptor element is quite simple at this moment and that
in Java we 
> have only single class inheritance, I would rather see "extends" as an attribute in class-descriptor.
> 
> Another problem that I see at this moment is: when defining a class mapping and considering

> inheritance too, we have to deal with 2 hierarchies: Java hierarchy and also node type
hierarchy. I 
> think it is not possible to define a Java hierarchy that is persisted on different/unreleated
node 
> types. What I am trying to say is: if B extends A, B is of type node:b and A is node:a
than node:b 
> must inherit from node:a.

Hmmmm.... I might be wrong abou this one. Must think about it.

./alex
--
.w( the_mindstorm )p.

> 
> At the first glance the part about the query should work. Still, I don't see how you
will be able to 
> decide after fetching the nodes which object to instantiate: ContentImpl or FolderImpl?
How can you 
> decide it? Considering that both classes can be persisted to the same node type, than
I cannot see a 
> way to differentiate them. Reading a node property set and deciding upon this if a ContentImpl
or 
> FolderImpl must be initialize is not gonna work.
> 
> 
> 
>> 2/ Interface  : I don't understand why mixin node types should be use.
>> Java interface have not some attributes. So, I don't see how it can be
>> set into the JCR node type hierarchy.
>> I think we can also reuse the extent-class element but more
>> modification in the current code is required. Still thinking about
>> that.
>> 
> 
> I am not sure about this point :-S.
> 
> ./alex
> --
> .w( the_mindstorm )p.
> 
>> 
>> 
>> --
>> Best regards,
>> 
>> Christophe
>> 
> 
> 


Mime
View raw message