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 13:18:26 GMT
Nicola Ken Barozzi wrote:

>----- Original Message -----
>From: "Santiago Gala" <>
>To: <>
>Sent: Tuesday, January 15, 2002 1:22 PM
>Subject: Re: Cocoon and Jetspeed portal
>>Nicola Ken Barozzi wrote:
>>>----- Original Message -----
>>>From: "Michael Homeijer" <>
>>>To: <>
>>>Sent: Tuesday, January 15, 2002 10:29 AM
>>>Subject: Cocoon and Jetspeed portal
>>>>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.
>Yes, good point.
>>>>- Build portal actions, portal layout stylesheet, portlet logic sheets
>>>>portlet configuration layout in Cocoon. This would be a lot more work
>>>>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
>>>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).
>Well, hope you remember me ;-) , I'm the guy that needed to configure his
>WAP phone.
Yeah, then somebody said "Look at the kiosk for a Phone magazine", and 
we noticed that the kiosk was really ;-)

>I remember the discussions well :-)
>>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 agree.
>What roadmap do you propose?
I don't have such clear views. To get something working fast, a PSML 
Generator could be written that uses services in jetspeed/turbine to 
authenticate, get a PSML file and then would aggregate the referenced 
portlets, controllers, ... But these also would need to be rewritten as 
Cocoon generators. The output  of the PSML generator could be any XML 
(something like (Basic)XHTML for inline and block markup at the portlet 
level, XLINK for links, maybe XFORMS for forms, PSML-like markup for 
controls and controllers). Transformers later on would take care of 
handling the XFORMS (see the exformula project), and resolving the links 
in meaningful ways. A serializer would turn it into wap or html, 
depending on the request capabilities.

It could be tricky, but I think a working toy implementation could be 
delivered in a reasonable time. This depends a lot on resources 
available, time, etc. This implementation could serve as a testbed for 
the concepts, and suggest changes to the architecture, etc.

>Is authenticaion-authorization-userprefs more important than PSML use?
In terms of "doing it right", no. In terms of "delivering something real 
soon now", yes. So, it depends a lot of the pressure you are under. What 
is important about PSML is that it tries to abstract aggregation at the 
rendering level, so you have a language to express that a group of 
portlets should be shown in column, or the selected one should be shown 
and the others accessible like in tabs. This can be done at the sitemap 
level, but it will break concerns if you try to do it dynamically , as 
the sitemap is *not* dynamic.

On the other hand, the user management is crucial to any portal 
implementation, as you are managing resources per user (like the default 
home page, etc.).

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

View raw message