cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <>
Subject Re: Cocoon and Jetspeed portal
Date Tue, 15 Jan 2002 12:22:47 GMT
Nicola Ken Barozzi wrote:

>----- Original Message -----
>From: "Michael Homeijer" <>
>To: <>
>Sent: Tuesday, January 15, 2002 10:29 AM
>Subject: Cocoon and Jetspeed portal
>>For a portal prototype I am trying to describe how it should be built
>>Cocoon. I have read about jetspeed and I tried to implement a portal page
>>Cocoon. If i could use the portlet mechanism from jetspeed, this would
>>really simplify building a portal with Cocoon.
>Apart from any opinion on portlets, there is a JSR too that wants to
>standardize portlets, headed IIRC by IBM.

Latest news! There are *two* jsrs 162 and 167, which looks like there is 
a political fight around the area... ;)

I don't know what will come out of this thing. I'm trying to be present 
(either as individual, or appointed by Soluziona Software Factory) in 
the process.

>>I can see two ways of achieving this:
>>- Access cocoon from jetspeed.
>I haven't seen jetspeed recently, but it's how jetspeed usees/d cocoon.
Current cocoon support is broken in Jetspeed, and it is better that it 
continues broken until we devise better mechanisms.

>>- Build portal actions, portal layout stylesheet, portlet logic sheets and
>>portlet configuration layout in Cocoon. This would be a lot more work and
>>the overlap with jetspeed would probably be very big. I cannot see if
>>jetspeed is "componentized" enough to use these components in Cocoon.
>This is very interesting. As for layout, you can see that cocoon examples
>mimic a dashboard, a personal portal.
>IMHO porlets are conceptually a Reader; cocoon pipelines are more flexible,
>but it could be a great idea to be able to use ready-made portlets in
>What is really missing in Cocoon, IMHO, is user handling. This is what is
>really needed.
>Authentication, authorization and preferences.
>There was a suggestion back then to make it possible to use Turbine (IIRC
>it's what jetspeed uses) in Cocoon too.
We have had some discussions around the issue back (with Ricardo Rocha, 
Stefano, and other people around in ApacheCons).

Jetspeed uses PSML to describe the page structure. It is a XML file 
format which specifies the page layout in terms of portlets, portletsets 
(group of portlets), portletcontrols (decorations, such as title bar, 
etc) and portletcontrollers (ways to handle a portletset like menu, tab, 
column, ...)

While the format of the PSML is not satisfactory, I think it is a place 
where cocoon effort could hook with our effort. A cocoon generator could 
be implemented that interprets a PSML resource in terms of other cocoon 
generators (portlets) and transformers (controls).

There is a lot of work missing here, and I'm sure that both the PSML 
syntax and jetspeed and cocoon developers pre-conceptions will change in 
the process. But I think we are getting to the point where it is needed. 
I don't think Jetspeed people would be against it either, at least if 
changes are proposed incrementally in ways that will not break a lot of 
existing implementations.

In discussions we had in Jetspeed list, there were two differents points 
of view:

- people that thought that a portal was made by aggregation at the byte 
stream level (like what jsp or velocity does, like what current jetspeed 
- people (I count in this group) that thought that the approach to 
aggregate SAX event streams (a la cocoon) was much sounder, in that it 
would allow multidevice support and a lot of added benefits while 
simplifying the global design. I am working for a company that has a 
tool to make portals this way, based on jetspeed (, 
and we are quite satisfied with the results.

A consensus was reached, and the original Portlet API proposal (I don't 
know yet if the jsr has changed it a lot) included two portal container 
classes: the *classic* one and the SAXPortlet based one. It included 
also SAXPortletRequest, SAXPortletResponse, ... SAXPortlets were 
required to return whole documents (no markup spec), not fragments.

I agree that a lot of the authentication, authorization and preferences 
part of cocoon is missing currently. But this should not refrain us from 
starting moving in the right direction.

I hope this helps.

To unsubscribe, e-mail:
For additional commands, email:

View raw message