Hi, On 2/14/07, Jukka Zitting <[EMAIL PROTECTED]> 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
