On 7/14/06, Jukka Zitting <[EMAIL PROTECTED]> wrote:
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.
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. 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. Using a OCM tools like this gives other advantages, for example : * Query loading strategy can be defined in the mapping file with proxies and the auto-retrieve option (same for updating object graph - see the option auto-update). * Migrating an existing content object model to support a JCR repo can be done without modifying the model implementation. We can have the same reflexion for ORM tools and JDBC.
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 ? -- Best regards, Christophe
