Hi, On 7/14/06, Christophe Lombart <[EMAIL PROTECTED]> 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/ - [EMAIL PROTECTED] Software craftsmanship, JCR consulting, and Java development
