incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christophe Lombart" <christophe.lomb...@gmail.com>
Subject Re: Graffito release plans?
Date Fri, 14 Jul 2006 12:50:55 GMT
On 7/14/06, Jukka Zitting <jukka.zitting@gmail.com> 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

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