When we founded Graffito, our goal was to provide a generalized CMS API
to all CMS backends for our web applications. At the time, JCR was not
public. The APIs in Graffito today have been around for over four years
in their general form. They are used in production (with proprietary
implementations behind them). In short, they are very simple, straight
forward CMS APIs that really haven't required a lot of change over the
years. Since then, JCR has come out, but these APIs still do exist.
A second goal was to provide a set of portlets for generalized
navigation, interaction and administration of content. A third goal was
for normalized URI access to portlet content, such as the ability to
mount heteregenous CMS systems onto the same URI space in a portal. The
fourth goal was to integrate a common security model between the portal
and content.
After the project was established, the community developed a
content-to-business-object-mapping framework. This framework makes
developing business applications, in the presentation layer (such as
portlets) more natural for developers to productively work than directly
programming to the JCR API, which is abstract in comparison.
There is no question in my mind that goals two, three, and four are
still relevant areas. The first goal, the API should be discussed. I
have personally never used the mapping framework, but from what I hear,
its a very cool contribution.
If we decide that the Graffito API is redundant and no longer necessary
to maintain, then an effort would need to be made to deprecate the API,
and move the graffito portlet applications written to that API to the
JCR API.
You also touched upon a point that has value to me: the hub of
repositories. In my project, we have the ability to add new repositories
to the server, and maintain the connection information with a set of
maintenance portlets. We have a need for this kind of modeling. I
believe its a good area for Graffito, since its about management of
content in the model and presentation layer.
Edgar Poce wrote:
Hi,
I'm working in a project that uses j2, we plan to keep using it in
the near future and we'd like to use the cms features described in
graffito's web page. I browsed the sources and I have the same doubt
that started this thread.
I don't understand what's the purpose of the webdav\filesystem\ojb
servers. I think one of the purposes of jcr is to provide that layer
on top of existing repositories. Moreover, most of the services the
graffito api provides seem overlapped with jcr.
My understanding is that most CMS features belong to a layer on top
of jcr. Is there any reason for not using jcr as the only api to
interact with the repository and build services on top of it?
In any case, if there's the intention of building a repository that
works as a hub of plugged server implementations, why not to build
that integration layer as a JCR implementation leaving the CMS unaware
of that?.
thanks in advance,
edgar
