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 22:01:49 GMT
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 <christophe.lombart@gmail.com> wrote:
> 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
>


--
Best regards,

Christophe

Mime
View raw message