Cocoon and Jetspeed

[Neeme Praks <ne...@one.lv>]

Sorry for crossposting this, but I feel that this theme covers the
topics on both of these lists...

Lately I have been doing some thinking about the integration of Cocoon
and Jetspeed. Now I would like to share my ideas/comments with others
and hopefully get some feedback and discussion about this.

I like the idea of the Jetspeed project, however, I see some places
where cocoon would fit in (and improve?) Jetspeed (or vice versa ;-)

Currently Jetspeed holds its configuration data as psml/xml files: one
file for all the portlets (portlet registry) and then individual files
for the actual portal pages that reference portlets in the registry.

When looking at cocoon framework, I realised that there is actually no
need for these files to be static (as they are currently). Instead, they
could be XSP pages, XML pages that Xinclude other pages (kind of
cascading registry for example), or pages generated by some other cocoon
producer. For example, I could store all my registry in the database and
then generate the portletregistry with XSP.

Also, the individual portal pages (e.g. default.psml) could be served by
cocoon, either static files or dynamic ones. In fact, jetspeed could be
a cocoon producer that is registered to hande all files with extension
"psml". This way I could place there "portal" pages anywhere on my
cocoon site and have jetspeed assemble the actual page with portlets.
The user personalization could also be achieved by dynamic XSP pages:
the PSML content would be rendered according to information in the
requested URL and authentication/authorization provided by servlet
engine/cocoon/(turbine?).

This would allow me to define many "public" portal pages (consisting of
portlets) across my site and also provide users with personalization
scheme most appropriate for me.
For example, I want to give my users the possibility to have more than
one totally personalized page (users can put these pages together by
choosing the portlets to be included on the page); I can do that by
making some page totally dynamic and database driven.
On the other hand, some pages can be "semi-personalized": when anonymous
user is accessing them, they would always return the same set of
portlets (by returning some static file for example)... However, when
authenticated user is accessing them, I can provide the user with
customization features (through dynamic generation), disable some
portlets, etc.
Finally, there could be totally plain static and simple pages that
always return the same set of portlets, regardless who would be
accessing them...

I also have some ideas about using cocoon inside the portlets...
All portlets could return some XML representation enclosed in some
agreed upon tags and attributes. For example, i could return something
like this:

<portlet>
    <border bordersize=3 titleBG="#000000">
        <xml-stylesheet href="HTML XSLT sheet" type="text/xsl"/>
        <xml-stylesheet href="ie5 XSLT sheet" type="text/xsl"
media="ie5"/>
        <xml-stylesheet href="WAP XSLT sheet" type="text/xsl"
media="wap"/>
    </border>
    <content>
        <xml-stylesheet href="HTML XSLT sheet" type="text/xsl"/>
        <xml-stylesheet href="ie5 XSLT sheet" type="text/xsl"
media="ie5"/>
        <xml-stylesheet href="WAP XSLT sheet" type="text/xsl"
media="wap"/>
            .... portlet content ....
    </content>
</portlet>

The border tag would specify the preferred way (specified by portlet
developer) how the "border" of the portlet would be rendered. The user
could override these settings with some system-wide theme for border
rendering. The content tag would include the XML content of the portlet
as well as stylesheets for transformation of this content to appropriate
client.

The use of this kind of system would also enable the possible use of
"remote portlets": XML pages (that follow the portlet DTD) residing on
remote server that could be rendered as portlets on local server...

I hope all this makes sense to somebody... maybe i'm totally caught by
the flexibility syndrome, but let me know what you think of all this ;-)

Neeme

PS. Sorry if I missed some critical points that make this whole idea
totally useless...

Re: Cocoon and Jetspeed

[burtonator <bu...@relativity.yi.org>]

Neeme Praks wrote:
> 
> Sorry for crossposting this, but I feel that this theme covers the
> topics on both of these lists...
> 
> Lately I have been doing some thinking about the integration of Cocoon
> and Jetspeed. Now I would like to share my ideas/comments with others
> and hopefully get some feedback and discussion about this.
> 
> I like the idea of the Jetspeed project, however, I see some places
> where cocoon would fit in (and improve?) Jetspeed (or vice versa ;-)

So do I :) 
 
> Currently Jetspeed holds its configuration data as psml/xml files: one
> file for all the portlets (portlet registry) and then individual files
> for the actual portal pages that reference portlets in the registry.
> 
> When looking at cocoon framework, I realised that there is actually no
> need for these files to be static (as they are currently). Instead, they
> could be XSP pages, XML pages that Xinclude other pages 

How is Xinclude support in Xerces?  I haven't tested it yet.

> (kind of
> cascading registry for example), or pages generated by some other cocoon
> producer. For example, I could store all my registry in the database and
> then generate the portletregistry with XSP.

I have thought of this.  Using Cocoon *everywhere* really isn't
something I want to do.  Cocoon can fail and it also adds complexity.

The real benefit of this proposal would be to store the PSML in the
database.  This is something that is very important.  The problem is the
ideal situation hasn't come up yet.  I am trying to come up with the
"official" Jetspeed database/XML persistence mechanism (which would be
up for vote) but just haven't had time.  Right now there are a lot of
different solutions but they all don't tie together correctly (Ozone,
Castor, OPaL, BasePeer, EJB, XML, XML Schema).  There is a huge amount
of technical overlap in all these areas.  Each has their advantages and
disadvantages and I want to come up with an official proposal that
leverages all the advantages with none of the disadvantages.  For
example Ozone has really nice XML persistence but its datastore isn't
portable (IE you always use the Ozone datastore) but with
Castor/OPaL/BasePeer you get a portable database but you don't get the
nice, rich XML support without a lot of work.  The blend of the two is
needed.  I am also want to merge something we have at Excite called
GenAPI what should make all this easier.  IE Stay Tuned :)

> Also, the individual portal pages (e.g. default.psml) could be served by
> cocoon, either static files or dynamic ones. In fact, jetspeed could be
> a cocoon producer that is registered to hande all files with extension
> "psml". This way I could place there "portal" pages anywhere on my
> cocoon site and have jetspeed assemble the actual page with portlets.
> The user personalization could also be achieved by dynamic XSP pages:
> the PSML content would be rendered according to information in the
> requested URL and authentication/authorization provided by servlet
> engine/cocoon/(turbine?).

User personalization will be achieved with XSP.  Just a little
different.  We can go into this in depth if you want.
 
> This would allow me to define many "public" portal pages (consisting of
> portlets) across my site and also provide users with personalization
> scheme most appropriate for me.
> For example, I want to give my users the possibility to have more than
> one totally personalized page (users can put these pages together by
> choosing the portlets to be included on the page); I can do that by
> making some page totally dynamic and database driven.
> On the other hand, some pages can be "semi-personalized": when anonymous
> user is accessing them, they would always return the same set of
> portlets (by returning some static file for example)... However, when
> authenticated user is accessing them, I can provide the user with
> customization features (through dynamic generation), disable some
> portlets, etc.

You can do this now.  It just isn't implemented anywhere.  I think
multiple customized pages is important.  IE I want an 'Open Source' and
then a 'World News' page

> Finally, there could be totally plain static and simple pages that
> always return the same set of portlets, regardless who would be
> accessing them...

yup.
 
> I also have some ideas about using cocoon inside the portlets...
> All portlets could return some XML representation enclosed in some
> agreed upon tags and attributes. For example, i could return something
> like this:
> 
> <portlet>
>     <border bordersize=3 titleBG="#000000">
>         <xml-stylesheet href="HTML XSLT sheet" type="text/xsl"/>
>         <xml-stylesheet href="ie5 XSLT sheet" type="text/xsl"
> media="ie5"/>
>         <xml-stylesheet href="WAP XSLT sheet" type="text/xsl"
> media="wap"/>
>     </border>
>     <content>
>         <xml-stylesheet href="HTML XSLT sheet" type="text/xsl"/>
>         <xml-stylesheet href="ie5 XSLT sheet" type="text/xsl"
> media="ie5"/>
>         <xml-stylesheet href="WAP XSLT sheet" type="text/xsl"
> media="wap"/>
>             .... portlet content ....
>     </content>
> </portlet>

Of course.  This is HUGE.  We really need to have multiple content
representation support.  In almost ALL situations this will be done with
Cocoon.  
 
The sitation should be a little different.  Mainly because of
subscription support.  If someone comes from a WAP device and wants to
create a customized page, Jetspeed needs to do some introspection to see
which portlets the user can subscribe to (IE an HTML and WAP don't
mix).   

The above would only work for Cocoon portlets.  I don't want a situation
where we require Cocoon.  Some people might not ever care about Cocoon. 
IE the Jetspeed Admin console doesn't use Cocoon because if Cocoon
breaks you can't use the Admin console to fix it :)

> The border tag would specify the preferred way (specified by portlet
> developer) how the "border" of the portlet would be rendered. The user
> could override these settings with some system-wide theme for border
> rendering. The content tag would include the XML content of the portlet
> as well as stylesheets for transformation of this content to appropriate
> client.

We also need a better way to represent the rendered Portlets and their
HTML.  But I think this should be done with CDATA sections withing
portlet markup and then XSLT this into an XHTML document with Cocoon.
 
> The use of this kind of system would also enable the possible use of
> "remote portlets": XML pages (that follow the portlet DTD) residing on
> remote server that could be rendered as portlets on local server...

Hm.. That is interesting.  Performance would be an issue.  What
advantages would this give?  
 
> I hope all this makes sense to somebody... maybe i'm totally caught by
> the flexibility syndrome, but let me know what you think of all this ;-)

The whole thing is just rather interesting.  Cocoon rocks and I want to
use it as much as possible.

Kevin

-- 
Kevin A Burton (burton@apache.org)
http://relativity.yi.org
Message to SUN:  "Please Open Source Java!"
To fight and conquer in all your battles is not supreme excellence;
supreme 
excellence consists in breaking the enemy's resistance without fighting.
    - Sun Tzu, 300 B.C.