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: using jcr mapping for Document Management System
Date Tue, 06 Feb 2007 10:02:32 GMT
On 2/6/07, ruchi goel <Ruchi.Goel@sun.com> wrote:
>
> Hi,
>    I am trying to design Document Management System using JSR170
> impl(Jackrabbit).
> Checked out graffito framework but it has its own complex layers for
> persistence  conversion, versioning, locking.


What is it complex the complete Graffito Stack or the JCR OCM tools
(JCR/object mapping) ?


JSR170 impl already provides implementation for versioning, locking etc.
> I found jcrmapping layer very useful for persistence , services and
> mapping java objects to nodetypes.
>
> Few questions :
>
> 1. Is it a good idea to use only jcr mapping layer and design a Document
> Management System .? Depend on JSR170 impl for versioning, locking etc.


You are free to do it but personnally I think it is not a good design. You
are mixing 2 different kind of API in the persistence layer.
Maybe for performance reasons, it could be justifified.

That's the same with JDBC & Hibernate.


2. Checked out the model for  CmsObject,Document,Folder and their
> corresponding mapping files in test code . These seem to inherit from
> nt:base and then all basic properties fr files/folders seem to havebeen
> custom defined. Why can't we use nt:folder as supertype for
> graffito:folder and nt:file as supertype for graffito:document  and
> inherit the properties as it is , instead of defining them in mapping
> files.



Well, this situaiton is used only for the unit tests. We should add more
unit tests with the classical jct node types like  nt:folder, ....
The OCM tools gives you the freedom to define your own content model and map
them to the more appropriate jcr node type.
You are not mandatory to use the CmsObject, Document, Folder classes. Sorry
for the confusion in the unit tests.


br,
Christophe

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