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 23:35:22 GMT
On 2/9/06, Alexandru Popescu <the.mindstorm.mailinglist@gmail.com> wrote:
> Hi Chris!
>
> Those suggestions look really interesting.
> But, I would really like to have a stable enough version with correct exception handling
and clean
> code. Moreover, before starting to support advanced features, we must cover the normal
usage
> scenarios first. Afterwards, the way is free to add support for those.
>

Next month, one guys in my company will start the first Graffito
modules (GraffitoNews & GraffitoForum).
We needs inheritances, interfaces for that. I would like to start the
implemenetation asap.
How long is necessary for your code clean  up ? what is it exaclty ?
Is it mainly the exception handling ?


> Indeed i find interesting the lazy loading and auto-updates. Still I believe that some
of these
> features can be supported immediately we have inheritance for example (by using light
classes).

sorry I don't understand - How can we support inheritance ?

> This
> is the main raison I am trying to keep focus on having the full functionality in place.
Some of
> these features are quite complex to be implemented (take for example lazy loading).
>
auto-retrieve, auto-update are not complex. We have to add some
conditions in the PM.
I think a java proxy can help for the lazy loading but yes it is more
complex. we need to keep a reference to the PM in the java proxy.
Inheritance, interface : that' so cool but not so easy :-) but why not
too make some experiences, prototyping, ...

> Please don't take me wrong :-), but I would really need an usable version, before being
able to
> start thinking at those.

Please, let's review together how we can split the work. Currently it
is not a full time job but I can find a lot of time during the
upcoming weeks. My plan is to start the inheritance/interface coding
in the middle of the next week. Now, we can at least share ideas and
speak about the design.






>
> cheers,
>
> ./alex
> --
> .w( the_mindstorm )p.
>
>
>
> #: Christophe Lombart changed the world a bit at a time by saying (astral date: 2/8/2006
11:57 PM) :#
> > 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