incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <>
Subject Re: Graffito release plans?
Date Fri, 14 Jul 2006 13:13:10 GMT

On 7/14/06, Christophe Lombart <> wrote:
> Maybe not for the basic objects. It is will be more interesting when we will
> add new modules (news, forum, custom applications,....).  Futhermore The
> object model (aka data objects) should be independant on the persistence
> layer.

Yes, but do you require the persistence layer to implement the model
interfaces using pure data objects? Then why not define the data
objects themselves as the API and just get rid of the interfaces?
After all, there is only one reasonable data object implementation of
for example the CmsObject interface.

> Why do you want to add specific JCR code in the data objects ? I don't like
> the idea to add specific implementation in data objects. Thoses objects
> should contain only attributes with their getter/setter.

I'm probably missing something, so please hang on with me... As far as
I've understood, your components use the interfaces defined in
org.apache.portals.graffito.model in the api subproject. Thus for
example they call CmsObject.setProperty() to set a generic string
property. Why should this call be first routed to a Java setter and
only then mapped to a JCR Node.setProperty() call by the OCM tool?

> > That's what I was asking. :-) Is there a component that uses the
> > features of the underlying storage outside the API defined in the core
> > model?
> not yet. This is a good question. Do you see some use cases which will
> require this ?

Not really, just checking. If something like that is needed, then it's
best handled by extending the core model.


Jukka Zitting

Yukatan - -
Software craftsmanship, JCR consulting, and Java development

View raw message