incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Edgar Poce" <edgarp...@gmail.com>
Subject Re: Why the Webdav-/Graffito-/FileSystemServer interfaces?
Date Sat, 02 Sep 2006 02:32:06 GMT
Hi,

  Please bear with me and let me know if I'm spamming the list, I told
I'm new to CMSs. I gave the thing a second thought and I think that
both approaches can play quite nicely. A part of the CMS can act
directly at the content level (jcr portlets and jcr network
interfaces) and another part work at a higher level of abstraction
(GFT services) providing a subset of the features in order to ease the
development and integrating nicely with OO designs.This way the GFT
api would maintain its simplicity and leverage the jcr features and
some extensions (e.g. an audit trail at the content level) that act at
content level.

There's only one drawback that comes to my mind: since the content
will be touched from many places all the constraints and security
policies should be handled at the repository level in order to
guarantee data integrity. That would probably lead to extend the
repository constraint functionality through decoration or whatever
strategy.

WDYT? has it any sense?. Anyway, I'm working on the wysiwyg jcr
portlet to show how a porlet "content" mode would look, I'll share it
asap.

br,
edgar

                       -----------------------
                             gft modules
                       -----------------------
                             gft services
       --------------  -----------------------
        jcr portlets   gft persistence service
       ----------------------------------------
webdav |->   jcr      | rdbms | fs | webdav
cifs   |
nfs    |
ldap   |
etc.

Mime
View raw message