cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] Cocoon2 and Turbine and Jetspeeed integration
Date Mon, 28 Feb 2000 16:41:52 GMT
Raphaƫl Luta wrote:
> "Kevin A. Burton" wrote:
> >
> > Stefano Mazzocchi wrote:
> > >
> > > Yes. Both JetSpeed and Turbine are trying to incorporate Cocoon
> > > capabilities into them... I think they can't possibly do this without
> > > loosing much of the functionality, expecially the sitemap.
> > >
> > > So I'll push to go the other way around: reimplement JetSpeed on top of
> > > Cocoon.
> > >
> > <snip>
> >
> > Jetspeed isn't really a technology like Cocoon or Tomcat or anything.
> > It is more just a place to take multiple projects and incorporate them
> > into one framework (RSS and
> > OCS/Messaging/Projects/iCalendar/Discussion/etc).  Avalon will be big
> > there.  You can use Cocoon to drive Jetspeed 100% if you want.  It
> > doesn't care.
> >
> > Jetspeed really just sits on top of Turbine/Cocoon/Tomcat to provide a
> > Portal.  This includes user subscription to multiple XML data
> > sources/user authentication/ etc.  I am +1 at federating this out.  I
> > was really strong at creating the Turbine project because most of the
> > code would have had to be done within Jetspeed.
> >
> I think the main contention point between Jetspeed and Cocoon is not in Jetspeed
> but in Turbine, or to be more to the point the display processing
> functionalities
> of Turbine.
> However I don't think Jetspeed should be "re-implemented" on top of Cocoon, it
> should just offer 2 ways to drive its display:
> - either through Turbine programmatic layout/screen/portlet incremental
> rendering
> - or through Cocoon 2 global sitemap-processing filtering rendering
> Both approaches have merits and cater to different working teams (Turbine
> being developper friendly whereas Cocoon is webmaster oriented) and different
> business needs (Turbine for web applications and Cocoon for content
> publication).
> Even though a complete integration of Turbine/Cocoon would be very welcome, it
> really doesn't seem that easy so maybe a few bridges here and there would
> be enough for now... ;)
> As Kevin said, Cocoon can currently be used for rendering in Jetspeed.
> Cocoon should have a way to get more information on a content to be rendered
> in order to fully leverage the forthcoming sitemap and I think that would be
> best implemented by using custom URLs in the sitemap and allowing external
> applications to add specific URLHandlers (more about this when it is clearer
> in my head...)
> If we add to that an XSP taglib for accessing Turbine services, that would be,
> IMO, a decent start...

I'm all +1 for it. Really.

I do see the power of Turbine for web-app creation, but I'd like to show
that Cocoon 2 is not as content-oriented as Cocoon 1 is. The sitemap
works as the glue between your resources, exactly like the avalon
configuration file glues blocks into servers.

If we make XSP taglibs for Turbine services + a layout driven approach
that matches Turbine screens (coming up next), this is not just a decent
start, it's the definite end.

At least, from my point of view. Of course, others won't follow, but I
don't want to force anyone to do anything... we'll show the power of
Cocoon2... you then decide.

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche
 Come to the first official Apache Software Foundation Conference!  
------------------------- http://ApacheCon.Com ---------------------

View raw message