incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sandro Böhme <s.boe...@inovex.de>
Subject Re: JCR integration proposal
Date Tue, 29 Mar 2005 10:21:13 GMT
Hello,

 > * I would like to create a new subproject which will contains a JCR
 > mapping framework. The goal of this framework is to store any java beans
 > (CmsObject) in a JCR repository.This framework will be used by the JCR
 > ContentStore implementation and if needed,  can be used outside the
 > Graffito engine. After a lot of discussion on that topic, I would like
 > to start with a very simple solution  based on a converter class for
 > each CmsObject types (Document, Folder, ...). So if a new CmsObject
 > class is required for a custom application, the developer has to write a
 > new JCR converter class. Later, we can write more advanced/generic
 > converter implementations based on introspection or similar techniques.

Would that mean, you will have a nodetype for each class? How do you 
plan to organize the JCR-nodes?

After some research, I think we will have the best tool support, if we 
implement it according to JDO. This would give us a support for the 
description of the mapping for example. But (maybe just for me) it is an 
extensive api, so I would see it as a long term destination. BTW: It was 
already suggested by somebody on the jackrabbit mailing list.

In short term I would make sure, the organization of the data does not 
change very often because every change makes us not backwards compatible 
anymore. API changes are not that big problem in my opinion.

Using nodetypes for bean classes would let us specify node features for 
bean classes. E.G mandantory, auto-created, protected features.
We could see if one bean property is mandantory in the nodetype 
definition of the bean. When WebDav or JCR tools are used to change the 
node data this can not destroy the integrity of the data (e.g. creating 
a node which does not have the mandantory property). I would like to 
develop such a solution not only for Graffito but also for jackrabbit 
and our own project.
The disadvantage is, that jackrabbit does not support the registration 
of custom nodetypes in the repository at the moment. Day's JCR-tools do 
support it. I would check Day's license of the tools maybe we (I) can 
start developing with Day's JCR codebase until jackrabbit support the 
registration of nodetypes.
What's your opinion on that? Are you interested in a general, JDO 
supporting solution or do you need an immediate Graffito specific 
solution? As I don't want to slow down your work with a general solution 
I can work parallel on a JDO and node type based solution and later 
contribute it if you need it.
Whats your opinion on that?

Regards,

Sandro



Christophe Lombart wrote:
> Hi All,
> 
> I would like to start the JCR integration into Graffito.  This is a 
> summary on how I see this integration :
> 
> * I want to leave our persistence service as it is. I don't want to 
> replace it by a new JCR implementation. I don't want to change the 
> Graffito API which is *very* simple to use. I see only some minor 
> changes in the version & search services.
> * JCR integration can be made with a new implementation for the 
> org.apache.portals.graffito.store.ContentStore and a new Server class 
> (eg. org.apache.portals.graffito.model.JCRServer).
> * I would like to create a new subproject which will contains a JCR 
> mapping framework. The goal of this framework is to store any java beans 
> (CmsObject) in a JCR repository.This framework will be used by the JCR 
> ContentStore implementation and if needed,  can be used outside the 
> Graffito engine. After a lot of discussion on that topic, I would like 
> to start with a very simple solution  based on a converter class for 
> each CmsObject types (Document, Folder, ...). So if a new CmsObject 
> class is required for a custom application, the developer has to write a 
> new JCR converter class. Later, we can write more advanced/generic 
> converter implementations based on introspection or similar techniques.
> 
> 
> 
> What do you think about that ?
> Do you have some ideas, comments for such JCR mapping framework ? Is it 
> make sense for you ?
> 
> 
> Regards,
> Christophe
> 
> 
> 
> 

Mime
View raw message