incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christophe Lombart" <>
Subject Re: Graffito release plans?
Date Fri, 14 Jul 2006 14:14:15 GMT
On 7/14/06, Jukka Zitting <> wrote:
> Hi,
> 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?

Ok I think there are some confusions here - sorry !
If you review the OCM tools, look only in JCR/mapping and JCR/spring.

Other subprojects API, components, engine, ... are used for the Graffito
core services (the content plateform itself).
The OCM stuff is not yet integrated in this layer. Thoses core services are
not only focusing on JCR repo. Developers can plug propriatary repositories.
One Graffito goal is to group in the same "virtual content tree" different
content servers. Some of them can be JCR repo and others can be propriatary.
CmsObject is specific to this layer.

if you check the OCM unit tests (/components/src/test), this is not
mandatory to implements a specific interface and/or a specific ancestor
class. You are free to defined your own.

Best regards,


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message