incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christophe Lombart" <>
Subject Re: Graffito status followup
Date Wed, 14 Feb 2007 12:45:51 GMT
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,
* The code repository has to be reviewed in order to match to this new

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.


On 2/14/07, Jukka Zitting <> wrote:
> Hi,
> On 2/14/07, Christophe Lombart <> wrote:
> > On 2/14/07, Jukka Zitting <> 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

View raw message