incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Edgar Poce" <>
Subject Re: Why the Webdav-/Graffito-/FileSystemServer interfaces?
Date Fri, 01 Sep 2006 18:58:36 GMT

On 8/31/06, Christophe Lombart <> wrote:
> I don't know if it is possible to join this thread now but let me give
> you my point of view on JCR integration and object oriented design.

thanks for joining :)

> 3/ JCR API is low level and verbose for a business developers. The
> Graffito API is more simple for a business developer. I'm just curious
> to know you point of view on that.

I agree with you, personally I don't like the verbosity caused by
checked exceptions thrown by almost every method in jcr. I don't think
it's a good practice to use checked exceptions everywhere. The jcr
client code usually looks pretty ugly even if checked exceptions are
wrapped in runtime exceptions and caught at the top of the stack. IMHO
jcr lacks a runtime exception for the common "in case another error
occurs" which can be found all over the spec.

I agree with you that GFT api is much simpler from a developer
perspective, however it's not as feature rich as jcr, and I'd prefer
the CMS to focus on providing generic features for any content rather
than providing less features for a fixed set of types.

> 4/ One of the most important Graffito goals is to make abstraction on
> the repository nature. Users who have specific content repo can use
> Graffito. There need a new Server impl and a new ContentStore
> implementation. If needed, you can review some issues in this area.

Well, it doesn't seem so easy on top of jcr. If that's the main goal
of graffito it would probably make sense to use a custom api.

> So, now the real question is :
> Is it interesting to use a High level object model for my content application ?
> Personally, I would like to review in more details your point of view
> before taking a decision.

you should :), as I told I'm a newbie in CMSs so any help and feedback
is very much appreciated.

> Why not ot make a
> prototype based on your ideas ?

sure, I could make a prototype. From the list bellow, where I describe
a few items I'd love to see in graffito/j2, I'd like to make a
prototype of the second item. Is it the kind of prototype you had in

I plan to make a wysiwyg portlet that will store the html in an
nt:file node in the repository. The htlm content will be editable
either from the portlet or from webdav thanks to jcr-server contrib in
jackrabbit. And cms specific operations will be performed from the
portlet in edit or content mode (see item 2).

Independently of implementation details I'd like graffito/J2 to
provide a content root for each fragment of type portlet, a place to
put the specific data of a portlet instance in a given page. Something
similar to portlet preferences but with a more powerful api that
allows to manage structured and unstructured data (maybe a jcr node
:), unlike portlet preferences it should be shared among all the users
without the possibility to be user specific. In the use case described
it would have been very useful. Ideally, when the GFT page manager
implementation is finished, that portlet root node will we a child of
the psml, thus an entire branch of the portal could be versioned

I'd also like to see a new portlet mode in j2 powered by graffito, a
"content" mode which provides a GUI to manage the root node described
above. e.g. featuring versioning, locking, auditing, content lifecycle
managent (workflow, staging).
I don't know whether it's easy or not to add a new portlet mode in j2,
if it's not very easy I will implement this GUI as an edit mode in the

For graffito as an end user product I'd like to have.
- A generic crud portlet.
- A content type modelling portlet for adding new types.
- A template modelling portlet that maps templates to content types.
- A business process modelling portlet that provides out of the box a
set of default workflow actions. Edit, Authorize, Publish, Notify,
- A generic search portlet.
- An advanced search portlet
- A war portlet. A portlet that keep a copy of every war that was
dropped in j2, thus making the wars manageable by graffito services
(item 2).


> Anyway, JCR admin tools are interesting and all contribution are
> welcome in this area.
> br,
> Christophe
> On 8/27/06, Edgar Poce <> wrote:
> > Hi,
> >
> > On 8/27/06, Jukka Zitting <> wrote:
> > > The JCR API is unfortunately not too easy to implement on top of
> > > existing content repositories or content access mechanisms. My
> > > understanding is that the goal of the API is more to provide a
> > > standard and feature-rich platform for building new content
> > > applications rather than to be a lowest common denominator for easy
> > > integration with all existining content stores.
> >
> > I think I'm missing something here. For what I see the GFT API is not
> > used as an interface to integrate legacy data, its intention seems to
> > be to hide the implementation details of strategies that are optimized
> > for different persistent storages. However, based on David comments it
> > seems that there are propietary integration implementations. Sorry for
> > the noise in case I'm missing something obvious. comments?
> >
> > > Thus, until (or if ever) there are readily available implementations
> > > of JCR on top of filesystems, generic databases, WebDAV, etc. I think
> > > it makes sense for Graffito to have it's own abstraction layer
> > > especially when the goal is to be able to work with a number of
> > > different backends.
> > >
> >
> > Not sure, but is it worth to lose a feature rich api as JCR under an
> > abstraction layer with the goal of using different low level
> > strategies for storing content?.
> >
> > Not sure, but if the development effort is so high both for building a
> > level 1 jcr implementation for integration purposes and for
> > maintaining a custom API, wouldn't it be a better choice to build
> > custom ETLs to synchronize the repository with external content rathen
> > than mantaining a custom API?. Also not sure, but if the portlets are
> > built on top of JCR there will probably be more interest from the
> > community to colaborate, since it could be reused in other portals,
> > repositories, right?.
> >
> > A first example that come to my mind of a drawback and lose of code
> > reuse is the repository browser. Now, the GFT repository browser uses
> > it's custom api, wouldn't it be a better choice to build a generic JCR
> > repository browser?, actually there's already an open source desktop
> > implementation based on the eclipse platform. In case GFT uses JCR
> > that and other software could be reused. Given the fact that I still
> > don't fully agree with some decisions It's probably too early to offer
> > a contribution, but I volunteer give a try to code a web based JCR
> > repository browser for graffito in case there's interest.
> >
> > And the last but not least "not sure" :), wouldn't it make sense to
> > build a framework for implementing level 1 repositories?, I think your
> > contribution to jackrabbit, jcr-ext, would be a starting point, has it
> > any sense?
> >
> > > My concern for starting this thread was more related to the structure
> > > of the Graffito abstraction layer. I still don't quite see the
> > > rationale for using interfaces for plain data objects and the need for
> > > explicitly modelling the (configuration of) possible backend systems
> > > as separate Server interfaces.
> > >
> >
> > I fully agree with you on this.
> >
> > br,
> > edgar
> >
> > > BR,
> > >
> > > Jukka Zitting
> > >
> > > --
> > > Yukatan - -
> > > Software craftsmanship, JCR consulting, and Java development
> > >
> >
> --
> Best regards,
> Christophe

View raw message