portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Sean Taylor <da...@bluesunrise.com>
Subject Re: jcr page manager
Date Thu, 31 May 2007 16:27:30 GMT

On May 29, 2007, at 7:07 PM, Edgar Poce wrote:

> 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:
>> 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

Im in favor of keeping the file system Page Manager too
We are already have a Page importer feature in Jetspeed (but no  
Administrative portlet yet, see JS2-716)

> 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.
Security constraints can be editing in the Site Manager
Nested fragments are supported in both customizers
Menus and menu ordering still require XML editing, thats why I was  
hoping to get JS2-716 in for the next release, but imports can be  
done via the command line as well today

>> 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
Interesting. What license is this code developed under?
I will review the code and see what I think. In general I would like  
to not introduce anymore new ways to parse XML into Jetspeed
As I have stated on this list before, we have like 5 different ways  
to parse XML built into Jetspeed today such as Castor, Digester
Would be best to settle on one approach

>> > 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.
Yes, you can leverage a lot of the high level stuff for copying and  
cloning trees of PSML

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message