St�phane Croisier wrote:
This idea is very interesting but maybe it is too early. Do you have something to contribute for an cms-commons ?At 20:45 24/03/2005, David Sean Taylor wrote:
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 ?
For JCR integration, what do you think about Stephane's proposal of a "Lenya CMS Framework or Jackrabbit Framework"?
As mentionned I still think it would be great to try to open a a "cms-commons" community (as a side note, David, it would be great to have a "portal-commons" project too ;-) ) in order to federate what can be federated on top of the JCR RI rather than trying to reinvent the wheel and split the community.
I would think that the Graffito integration would be implemented with Jackrabbit, right?
I was thinking so (graffito being on top of Jackrabbit), but this description of Graffito looks more just like a JCR compliant API (which level?) on top of the current existing code base rather than a full refactoring.
BTW: Serge recently contributed an Hibernate + OJB persistance layer implementation for Jackrabbit... So here again is it really worth ajusting the current code base to get some JCR compatibility rather than refactoring the whole project on top of Jackrabbit (interfaces may then simplify content definition, templates development,...).
Well, I'm not sure you are undestanding how Graffito is designed. JCR support doesn't imply a important refactoring. It is just a new implementation for our ContentStore interface.
Just to clarrify , Graffito is not a only a JCR extension, it is composed of the different layers and tools :
* Mapping frameworks (should be commited soon) : we are building a POJO/JCR repo mapping which will be used in the Graffito persistence layer or outside Graffito. I think it is a good candidate for a cms-common. For us, it is not a good design to use the JCR model in all application layers (eg. : jsp, portlets, ...). it looks like using JDBC in each layer. We have in Graffito a CMS object model which is extensible depending on the cms application needs. I can't imagine to see a CMS application based only on objects like item, node and property. I prefer to see more "business" oriented objects like Document, Image, Folder, Forum, News, ...
* The persistence engine : this engine group different content repository into the same virtual content tree (JCR, simple graffito DB, propriatary content store,...).
* Graffito services : security, versionning, workflow (not yet complete) which are using the persistence layer.
* Graffito applications : news management, document management, CMS, forums, ... which are using the Graffito services.
Up to you to choose which layer you want to use. Please, let me know what's wrong ?
Christophe
