I modified the Graffito site and add information on the JCR mapping stuff.
I cannot update/commit because my laptop battery is break down and
cannot restart my laptop :-( Hope to solve this issue ASAP and publish
the new site.
On 2/8/06, Christophe Lombart <[EMAIL PROTECTED]> wrote:
> 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
>
--
Best regards,
Christophe
