cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lewis, Andrew J" <Andrew.Le...@jbosc.ksc.nasa.gov>
Subject RE: Cocoon and Jetspeed portal
Date Tue, 15 Jan 2002 14:29:29 GMT
If you look at the JSRs, 162 which is from IBM and only referecnes Jetspeed has only IBM supporting
it. 167 has support of Sun, BEA, Interwoven, Macromedia, Cirtrix, Vignette, etc., and also
references Jetspeed as well as other sources. 167 is a better prepared submission, and uses
the same starting point. Politics aside, they are both headed in the same direction. I'd look
more to 167 though - much broader support base....

> ----------
> From: 	Santiago Gala[SMTP:sgala@hisitech.com]
> Reply To: 	cocoon-dev@xml.apache.org
> Sent: 	Tuesday, January 15, 2002 7:22 AM
> To: 	cocoon-dev@xml.apache.org
> 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
> >
> >
> >>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
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message