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 Wed, 30 May 2007 02:07:01 GMT
Hi David,

 First of all thank you very much for your comments.

On 5/29/07, David Sean Taylor <david@bluesunrise.com> wrote:
> On May 29, 2007, at 6:25 AM, Edgar Poce wrote:
>
> > Hello,
> >
> >  I'm working in a page manager backed by jcr called JcrPageManager.
> > It is an extension of CastorXmlPersistenceManager but I'm not sure
> > whether it's a good idea to extend it because
> > CastorXmlPersistenceManager uses a FileCache which is unusable by a
> > JCR implementation. I guess this problem can be solved by implementing
> > a  PageManager which doesn't inherit from CastorXmlPageManager but I'd
> > like to reuse as much code as possible, WDYT?, how should I implement
> > a cache for the JCRPageManager? Any help is highly appreciated.
> >
>
> I really need to get a roadmap put together for the 2.2 release
> A JCR Page Manager is my personal top priority on the 2.2 roadmap
> So this is cool to hear you are getting a start on it
> Im not going to have a whole lot of time for this now as Im busy
> getting out 2.1.1
>
> Start by reviewing the DatabasePageManager
> Yes, we have a full database backend implementation of the page manager
>  From there review the page-manager component, and the shared classes
> between the file system (Castor) and DB impls
>
> AbstractPageManager
> DelegatingPageManager
> PageImporter
> PageManagerUtils
> PageManagerSecurityUtils
>
> There is a lot of code you should be able to leverage there in the
> same pattern
>

I'll make another JCRPageManager similar to the DB impl, I'll let you
know how it goes. Thanks for the tips.

> > You'll find some implementation details bellow, in case there's
> > interest I'd be happy to contribute the code to jetspeed. The code can
> > be downloaded from http://code.google.com/p/jcr-portlets/
> >
> > Br,
> > Edgar
> >
> > Some details about the JCRPageManager:
> >
> > 1. The mapping rules are read from the castor mapping file. A
> > converter class is responsible of converting j2 objects to jcr nodes
> > and viceversa based on these rules.
> >
>
> Im not too keen on perpetuating the usage of Castor...

in the prototype I'm not using castor, I made a PageManager that
inherits from CastorXmlPagemanager but surprisingly
CastorXmlpageManager hasn't any castor dependency.

As a side note, from a user perspective I'm in favor of keeping a file
system page manager, the castor implementation provides an easy way to
get started with jetspeed without the need to configure a database or
a jcr implementation. Besides, AFAIK there are many functionalities
that can be used only by editing the psml files, e.g. editing security
constraints or nesting fragments in a single page. Unlike the db or
jcr, editing the psml files in the fyle system is extremely simple.

> Are you making use of the Grafitto mapping work, or is this something
> different?
>

No, I make it in a class that handles the mapping based on the castor
mapping file, it doesn't mean that I use castor, I just parse the
castor mapping file to configure the jcr mapping, it can be reviewed
later but for the moment I'm happy with it because I don't need to
create a new configuration file nor add more dependencies.

I use this class to parse the castor file
http://jcr-portlets.googlecode.com/svn/trunk/jcr-page-manager/src/main/java/org/apache/jetspeed/page/document/jcr/JcrCastorMappingReader.java

I use this class to convert from j2 objects to jcr nodes
http://jcr-portlets.googlecode.com/svn/trunk/jcr-page-manager/src/main/java/org/apache/jetspeed/page/document/jcr/GenericJcrConverter.java

> > 2. The PageManager is an extension of CastorXmlPageManager. The only
> > difference with its superclass is that JCrPageManager takes a file
> > based CastorXmlPageManager instance as a constructor argument. In case
> > the site doesn't exist in jcr then JCRPageManager copies the entire
> > site from the file system to the underlying JCR implementation.
>
> Yes, I can see the advantages of extending CastorXMLPageManager too,
> as the handlers can be easily replaced
>

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.

br,
edgar

> >
> > 3. The FolderHandler given to the JcrpageManager is a JCR based
> > implementation.
> >
> > 4. The DocumentHandler given to the JcrPageManager is a JCR based
> > implementation.
> >
> > 5. The repository is accessed via a JcrProvider. I implemented two
> > strategies, the first uses jndi and the other instantiates jackrabbit.
> >
> > 6. The configuration is handled via Spring, I made a
> > jcr-page-manager.xml as a replacement for the default configuration
> > file.
> >
> > The current implementation still lacks the following features:
> >
> > 1. Cache
>
> Regarding the FileCache, its just a Spring component, but
> unfortunately its pretty old and never was converted to the interface-
> driven model found everywhere else in Jetspeed
> I think we can either replace the FileCache with a more general
> cache, or make the entire caching optional
>
> >
> > 2. Use the same authentication mechanism to login to the repository
> > than jetspeed.
> >   I guess it can be achieved by configuring jackrabbit to use the
> > jetspeed jaas login module but didn't try it yet.
> >
> We need to hook into Jetspeed authentication and authenticate
> Jackrabbit at the same time...
>
> > 3. Create j2 specific nodetypes, for the moment every node is created
> > with nt:unstructured as the primary type.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> > For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
> >
> >
>
>
>

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


Mime
View raw message