portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Edgar Poce" <edgarp...@gmail.com>
Subject Re: jcr page manager
Date Thu, 14 Jun 2007 16:02:15 GMT
Hi david,

On 5/29/07, Edgar Poce <edgarpoce@gmail.com> wrote:
> it was the easiest way I found to get a working jcr pagemanager,
> however, based on your previous comment about the DB impl I understand
> that I should drop this approach and build a PageManager following the
> DB PageManager patterns.  I'll give it a try and let you know how it
> goes.

I gave a try to the approach we discussed but I found a few problems
to implement it. Because of that I had to keep the previous design to
get a working version. This new version is downloadable from
http://jcr-portlets.googlecode.com/svn/trunk/jcr-page-manager/. Feel
free to include in j2 whatever you consider a valuable contribution.


A brief description of the current implementation:

Provides the main JCR PageManager classes and a cache that uses the
jcr path as the key and jcr observation to remove stale entries.

Provides mapping from j2 object model to JCR by parsing the rules in
the castor mapping file

Provides utility classes to get a JCR session

Issues trying to implement a page manger without extending from the
castor implementation

- The database object model is different from the castor object model
then I couldn't reuse the mapping I've made for my previous attempt to
get a JCR page manager.

- I tried to use the jcr-mapping project from graffito/jackrabbit but
I found that the collections from the database object model are
coupled to the ORM  implementation (OJB), I mean that those collection
implementations are not standard (arraylist, vector, ...).
consequently I had to create customs converters to handle them. In
addition, I found that the security constraints in the object model
used in the database page manager are modelled with an implementation
for each object, thus I had to create a new mapping rule for each type
of security constraint. This made the jcr mapping file quite long and
hard to read, I guess my lack of experience with the jcr-mapping tool
increased this problem.

- After having failed to map the database object model to jcr I
decided to extend that object model as the castor implementation does
(org.apache.jetspeed.om.page.psml), it seems that extending the
database object model to override the db specific behaviour was the
right way to go. After several hours working in this I couldn't make
it to work correctly and I decided to go back to the previous design.

To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org

View raw message