cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Neeme Praks" <>
Subject RE: Cocoon and Jetspeed
Date Thu, 01 Jun 2000 14:00:24 GMT

> -----Original Message-----
> From: Stefano Mazzocchi []
> Sent: Wednesday, May 31, 2000 1:19 AM

[skipped a lot of relevant comments to Kevin]

> > Yep, I was thinking about this also, but I just didn't want 
> to make my
> > email any longer than it already was.
> > One solution would be that portlets would store their stylesheet
> > references in registry, so it would be obvious which ones 
> support which
> > media. However, this could centralize the administrative 
> work (less an
> > issue in the case of cascading registry).
> Don't you see you are simply cloning the Cocoon2 sitemap?

Yes, I see that ;-)
The comment assumed that we are leaving the Jetspeed in the current
state (using Cocoon). I agree with you that combining the registry and
sitemap would be a natural step in the case of Jetspeed becoming Cocoon

> > I would prefer the solution where portlets register/declare 
> themselves
> > to handle certain types of media but the actual information 
> about the
> > implementation of that support would be in the portlet and easily
> > modifiable by the portlet developer (also goes together 
> with the concept
> > of "remote portlets").
> A portlet is simply a page with a specific semantics. Period.
> Turn JetSpeed into a portlet generator, or even better, create portal
> taglibs for XSP and you're done. Everything else is handled 
> by Cocoon2.

yep, couldn't agree more ;-)
I was thinking along the same lines, just couldn't express it that well.

> > Then again, if we could drop the support for everything else than
> > cocoon, I think that would reduce the complexity... but we 
> wouldn't lose
> > anything in functionality, only gain... (OK-OK, I'm just speculating
> > here ;-)
> I totally agree. Turbine adds services that we can easily port under
> Cocoon (and I plan to do once we stabilize) and make 
> available as Cocoon components to other composers.

Oh I'm glad to hear that. And Jetspeed is much more a Cocoon app than it
is a Tubine app, due to the fact that it extensively uses XML.

> For what I see, I could be able to do the same with JetSpeed just as
> easily, turning JetSpeed portlets into pages and distributing JetSpeed
> functionalities across components that you can mix and match at need.
> NOTE: this _does_not_ mean everything will be incorportated into the
> Cocoon cvs module. We will provide the ability to "install" a 
> particular
> xml web application just by mounting a jar with a sitemap built in. So
> you say
>  <mount uri="/news" src:jar="./web-apps/jetspeed.jar"/>
> and bang, everything is already in place.
> But if you need to change the styles to match your logos or such, you
> un-pack the jar and update the stylesheets you need and so on.
> JetSpeed then can be just a sitemap/configuration, a collection of
> logical components and a bunch of static pages. And you can 
> concentrate
> in making your web-app more usable and powerful from a user 
> perspective,
> rather than from a logic perspective, since you reuse all the 
> logic and
> separation design patterns that Cocoon was designed upon.

well, what can I add... again, couldn't agree more ;-)

> Please, don't get me wrong: I think JetSpeed has great potential to
> become _the_ XML-web-application everyone will use on their web sites
> for both personal and business use.
> On the other hand, I think Kevin is simply following the 
> wrong path that
> leads to merging Turbine and content syndacation, something that I
> consider a hack since Turbine was _not_ designed with this in mind (I
> don't agree with Jon on the orthogonality of the two issues).
> I belive JetSpeed would make the right use of Cocoon2 functionality
> allowing you to concentrate in providing more features to your web-app
> rather than cloning services that Cocoon2 already implements.
> The price for this will be to refactor JetSpeed to base it on 
> the Cocoon framework.
> I see this as the only future-compatible solution... otherwise, you
> might well see people tearing apart your project and porting 
> the useful pieces over to Cocoon... which will be very sad :/

yep, I think this could be a _very_ realistic scenario... I was already
thinking about doing it ;-)


View raw message