[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xml-cocoon-dev
Subject:    Re: [RT] Cocoon2 and Turbine and Jetspeeed integration
From:       Stefano Mazzocchi <stefano () apache ! org>
Date:       2000-02-28 16:41:52
[Download RAW message or body]

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.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Come to the first official Apache Software Foundation Conference!  
------------------------- http://ApacheCon.Com ---------------------

[prev in list] [next in list] [prev in thread] [next in thread]