You are viewing a plain text version of this content. The canonical link for it is here.
Posted to graffito-dev@incubator.apache.org by Christophe Lombart <ch...@gmail.com> on 2007/02/06 10:02:32 UTC
Re: using jcr mapping for Document Management System
On 2/6/07, ruchi goel <Ru...@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
Re: using jcr mapping for Document Management System
Posted by Christophe Lombart <ch...@gmail.com>.
On 2/6/07, ruchi goel <Ru...@sun.com> wrote:
>
>
>
> 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.
You should create a new class descriptor which maps a java class to a
ps:folder. In this class descriptor try to map the ps:folder properties into
the java class attribute. If I remember correctly, nt:file has not a lot of
properties (creation date + children def based on HierarchyNode).
Re: using jcr mapping for Document Management System
Posted by ruchi goel <Ru...@Sun.COM>.
Christophe Lombart wrote:
> On 2/6/07, ruchi goel <Ru...@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
>