incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ruchi goel <Ruchi.G...@Sun.COM>
Subject Re: using jcr mapping for Document Management System
Date Tue, 06 Feb 2007 10:34:06 GMT
Christophe Lombart wrote:
> 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) ?

The graffito stack has its own set of services and persistence manager 
conversion.So, I feel there is added complexity in graffito stack  for 
the API which is now already exposed by JSR170.
>
>
> 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.
>
>
sorry for confusion. I am not mixing two kinds of API. What I meant was 
I will depend on  JCR persistence manager for versioning , locking etc.
> 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.

OK. So, if I have a ps:folder inheriting from nt:folder , how do I 
access from my model the properties which are nherited from nt:folder. 
My custom_nodetypes .xml will have :
<?xml version="1.0" encoding="UTF-8"?>
<!--
    /*
    * Copyright 2004-2005 The Apache Software Foundation or its licensors,
    *                     as applicable.
    *
    * Licensed under the Apache License, Version 2.0 (the "License");
    * you may not use this file except in compliance with the License.
    * You may obtain a copy of the License at
    *
    *      http://www.apache.org/licenses/LICENSE-2.0
    *
    * Unless required by applicable law or agreed to in writing, software
    * distributed under the License is distributed on an "AS IS" BASIS,
    * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 
implied.
    * See the License for the specific language governing permissions and
    * limitations under the License.
    */
-->
<nodeTypes xmlns:nt="http://www.jcp.org/jcr/nt/1.0"
    xmlns:jcr="http://www.jcp.org/jcr/1.0" xmlns:rep="internal"
    xmlns:mix="http://www.jcp.org/jcr/mix/1.0">
   
   <nodeType name="ps:folder" isMixin="false" 
hasOrderableChildNodes="false" primaryItemName="">
    <supertypes>
      <supertype>nt:folder</supertype>
    </supertypes>
  </nodeType>

</nodeTypes>

Thanks,
Ruchi

>
>
> br,
> Christophe
>


Mime
View raw message