Hi David, On 8/26/06, David Sean Taylor <[EMAIL PROTECTED]> wrote:
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.
Either way it's great your feedback that let me understand GFT internals and the causes of the decisions that were made. Thanks. br, edgar
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 > >
