Ok, it sounds great ! Before starting the refactoring, I would like to be sure that everybody is agreed. Can we summarize like this :
Main goals --------------- * Review the project to be more attractive and increase the community size. * Refactoring the Graffito project in order to be more a content management framework instead of a complete CMS product. As an alternative to many cms products, Graffito wants to provide a more modular approach. Refactoring the project : ----------------------------------- * Framework means a series of components/services that can be running alone (or integrated into specific applications). The framework offers also an integration with other existing frameworks/components. One good example is an integration with existing workflow engines like JBPM, OsWorkflow, .... * We have to define the component lists (in the first time, only for the "Graffito core" layer). * The first component to review is the current PersistenceManager. This one aims to access to different JCR content repositories which can contain any kind of content. Other backend systems will not be supported because it will add more complexities (eg. node type management, ...). * Each component has its own set of artifacts (jar, config file, dependencies...). * The code repository has to be reviewed in order to match to this new goal. The Content Model : ------------------------------ * Our content model has to be extensible without imposing specific content types. * The persistence layer will use the OCM tools to map java classes into a JCR repo. * A tools is required to register a new class definition into a JCR repo. When registring a new java class, this tools will create the corresponfing node types. Register a new content java class has to be as simple as register a new jcr node type. Let me know if it makes sense for you. br, Christophe On 2/14/07, Jukka Zitting <[EMAIL PROTECTED]> wrote:
Hi, On 2/14/07, Christophe Lombart <[EMAIL PROTECTED]> wrote: > On 2/14/07, Jukka Zitting <[EMAIL PROTECTED]> wrote: > > What I'm most interested in at this level is the content model. > > Currently Graffito has a predefined set of Document and other content > > types, but also uses generic bean persistence. Should the "Graffito > > Content Model" be fixed by better specifying the core content > > interfaces, or should the Graffito Core support arbitrary content > > objects? > > Good question. So, this is certainly the first tech aspect to review. > Our persistence layer should not force the developer to use a specific > content model. He should have the freedom to define its own interfaces > and classes. The current CmsObject has be also optional. JCR and our > OCM tools gives us this kind of flexibility. So, it should be possible > to have similar think in the core Graffito components. At least try to > have it with a prototype. Agreed. Having a fixed content model would effectively make Graffito just another content management system instead of a framework for such systems. However, having a flexible content model poses a number of open questions like how to handle typing or how to enforce specific relationships between documents or objects. JCR handles this quite nicely with the node type system. This is actually one of the main reasons why I'd rather make Graffito just JCR-based, as otherwise we'll need to come up with a similar typing mechanism that covers also other backend systems. BR, Jukka Zitting
