incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christophe Lombart <christophe.lomb...@gmail.com>
Subject Re: JCR mapping package naming
Date Wed, 08 Feb 2006 21:57:59 GMT
On 2/8/06, Alexandru Popescu <the.mindstorm.mailinglist@gmail.com> wrote:

> promoting it would be: "why is it portals?"
Because the targeted community is mainly the ASF portal :-)
We can try to write an article on the OCM concept and use graffito as
an example. than, we can promote OCM on the Jackrabbit list and other
areas.

>
> I am reviewing right now the collection converters and fixing the exception handling.
After this
> step, and some small refactorings in the filters, I will be ready for interfaces/inheritance.
Once
> those are done, or at least addressed we should start promoting it.
>
I'm interesting to add new attributes in collection-descriptor (cd)
and bean-descriptor (bd) (inspired from OJB) :
1/ lazy loading  : load the bean attribute or the collection attribute
when the getter method is called - not when the main object is
retrieved.
2/auto retrieve . this is an alternative to the the lazy loading. If
false, the bean attribute (or the collection attribute) is not
retrieved. The developer can use a new method defined on the PM to
load the object. I prefer the lazy loading solution but sometime it
can be usefull to control when loading the attribute.
3/ auto-update: if true : when the main object is updated, the
bean/collection  attribute is updated.If false, the attribute is not
updated. There a lot of case when the graph is loaded (eg. one folder
& its content)  and only updates are done on the main object.

Those attributes should gives the possiblity to support deep JCR
structures without loosing good performances.

What do you think ?

I'm also thinking about the inheritance/interface support :
1/ Inheritance : the class-descriptor can contain a new element 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>

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);

=> 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 ?

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.

--
Best regards,

Christophe

Mime
View raw message