cocoon-dev mailing list archives

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

>----- Original Message -----
>From: "Michael Homeijer" <M.Homeijer@devote.nl>
>To: <cocoon-dev@xml.apache.org>
>Sent: Tuesday, January 15, 2002 10:29 AM
>Subject: Cocoon and Jetspeed portal
>
>
>>Hi,
>>
>>For a portal prototype I am trying to describe how it should be built
>>
>using
>
>>Cocoon. I have read about jetspeed and I tried to implement a portal page
>>
>in
>
>>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
>cocoon.
>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 
does).
- 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 (http://definete.com), 
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message