Hi, On 8/31/06, Christophe Lombart <[EMAIL PROTECTED]> 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 mind? 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). 1. 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 at http://mail-archives.apache.org/mod_mbox/portals-jetspeed-user/200607.mbox/browser, 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 easily. 2. 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 prototype. 3. 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, etc. - 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). br, edgar
Anyway, JCR admin tools are interesting and all contribution are welcome in this area. br, Christophe On 8/27/06, Edgar Poce <[EMAIL PROTECTED]> wrote: > Hi, > > On 8/27/06, Jukka Zitting <[EMAIL PROTECTED]> 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 - http://yukatan.fi/ - [EMAIL PROTECTED] > > Software craftsmanship, JCR consulting, and Java development > > > -- Best regards, Christophe
