cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicola Ken Barozzi" <baro...@nicolaken.com>
Subject Re: Cocoon and Jetspeed portal
Date Tue, 15 Jan 2002 12:46:45 GMT

----- Original Message -----
From: "Santiago Gala" <sgala@hisitech.com>
To: <cocoon-dev@xml.apache.org>
Sent: Tuesday, January 15, 2002 1:22 PM
Subject: Re: Cocoon and Jetspeed portal


> 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
<snip/>
> >>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
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).

Well, hope you remember me ;-) , I'm the guy that needed to configure his
WAP phone.
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).

+1

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

+1

> 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 agree.
What roadmap do you propose?
Is authenticaion-authorization-userprefs more important than PSML use?

Ken
--
Nicola Ken Barozzi                 xml-cocoon@nicolaken.com

These are the days of miracle and wonder...
          ...so don't cry baby, don't cry...
                                                  Paul Simon

Mime
View raw message