incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Re: Graffito release plans?
Date Fri, 14 Jul 2006 12:20:54 GMT
Hi,

On 7/14/06, Christophe Lombart <christophe.lombart@gmail.com> wrote:
> The OCM tools looks like Hibernate, OJB, ....  this is not tied to a
> specific object model. The mapping file gives you the flexibility to map
> any kind object graph into a JCR structures (node & properties).

Exactly. However, at least based on my initial scan, it seems that
Graffito doesn't have a POJO object model (as in concrete value
objects), but uses interfaces of the core model as a kind of an SPI
layer. Thus there is a chance of either using direct JCR calls to
implement the interfaces, or doing it with separate Java objects and
the OCM tool.

> > Looking at the Server, Folder, and CmsObject interfaces,
> > it seems to me that a direct JCR implementation (without the OCM
> > mapping) would probably suit the needs even better.
>
>  Can you explain more ? I'm not sure that I understand you.

It seems like there is a very natural mapping between the Graffito
core model and the JCR node hierarchy. I'm wondering if a separate
Java object layer is needed between, i.e. would it be more natural to
have just JCRServer, JCRFolder, and JCRObject (etc.) classes that
implement the API using direct JCR calls?

There is certainly demand for a generic object-to-content mapping
tool, but I'm wondering if Graffito is actually the best candidate for
using it.

> > Do the components bypass the core model to access extra features of the OCM?
>
> Which ones ?

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?

BR,

Jukka Zitting

-- 
Yukatan - http://yukatan.fi/ - info@yukatan.fi
Software craftsmanship, JCR consulting, and Java development

Mime
View raw message