On 2/8/06, Alexandru Popescu <[EMAIL PROTECTED]> 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
