incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christophe Lombart" <christophe.lomb...@gmail.com>
Subject Re: Graffito status followup
Date Wed, 14 Feb 2007 09:05:18 GMT
Hi,

On 2/14/07, Jukka Zitting <jukka.zitting@gmail.com> wrote:

> > a. "Graffito Core" : all necessary low-level services to define, store,
> > manage, audit, request and search content. If needed, it can give an access
> > to different heterogenous content servers (JCR and propriatary servers).
> > Graffito core have to be extensible. For example, a workflow service could
> > be added into "Graffito Core".
>
> Personally I'm most interested in a pure JCR solution, but a pluggable
> storage layer is also fine.

Me too. I just want to maximize the abstraction between application layers.
Using the JCR backend +  our OCM tools will be more extensible than a
DB + OJB or Hibernate. If everybody are agree, I'm ok to drop the OJB
support. We can have a persistence later which access to several JCR
content repos.

> 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.

and you ? How do you see our content model ?


br,
Christophe

Mime
View raw message