cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From burtonator <>
Subject Re: Cocoon and Jetspeed
Date Sat, 03 Jun 2000 01:34:33 GMT
Stefano Mazzocchi wrote:
> XInclude is _not_ supported in Xerces. Donald wrote a processor/filter
> for both Cocoon1 and Cocoon2 that implements this.

I couldn't remember if this was a feature in 1.1 or not...
> > > I have thought of this.  Using Cocoon *everywhere* really isn't
> > > something I want to do.  Cocoon can fail and it also adds complexity.
> I completely disagree here.

It has already failed.  There were fixes necessary to XSP and Tomcat
integration.  I also don't like emulating the Servlet API :(

This will change in 2.0 though.
> I've seen JetSpeed and like the idea very much, but it could be made
> _much_ simpler and more easily extended by using the full power of
> Cocoon2. Of course, not being available, this is something hard to do so
> Kevin doesn't have any absolute fault in this.

+1024.  I need to be more active in this area but yes!
> But you must understand that Cocoon was not designed to be called! It
> must be Cocoon that calls you!!!
> If you need XSLT transformations simply call Xalan and be happy. If you
> want the _real_ power you need to flip your view of the world and
> redesign the baby over the functionalities that Cocoon2 provides.

A large amount of features will use Cocoon 2.0.  There are many areas
within Jetspeed I am unhappy with.  Our next release (similar to the
Cocoon 2.0 blue sky) will fix these as well.
> > I agree about the complexity and failing. It could be turned off by
> > default and static file used instead... However, I think it would be a
> > powerful option to have...
> Cocoon doesn't fail. Period. That's _NEVER_ an option.
> It's like implementing an HTTP server on your servlet just in case
> JServ/Tomcat stalls. That's plain silly.

Huh?  I never said that.  Certain things are just done different.  This
doesn't mean they are "wrong".  Just different.
> > > needed.  I am also want to merge something we have at Excite called
> > > GenAPI what should make all this easier.  IE Stay Tuned :)
> That the point! JetSpeed is an XML web application and should remain so.
> You are adding more and more technologies that should reside at Cocoon
> level. You should just _use_ them.

Yes.  Cocoon or Turbine.  There are already features I have added to
Turbine because I have needed them and I have submitted misc pathes here
> Database persistance of XML documents is something that _everyone_ is
> likely to need pretty soon in the server side world, not just JetSpeed.
> Mixing this API with JetSpeed would require people to jump thru loops in
> order to achieve that.
> I don't think that's your goal.

I never said this would be part of Jetspeed.  Actually what I am trying
to accomplish is something that everyone can use.  I don't care where
this ends up, Turbine, Cocoon, its own project.  I just want the code :)
> > Have you looked at prowler (available at
> > >From the information that I have got, it is trying to achieve very
> > similar goal... to provide common java api to heterogeneous information
> > sources...
> > (I'm not aware of the licencing issues, though)
> >
> > > User personalization will be achieved with XSP.  Just a little
> > > different.  We can go into this in depth if you want.
> >
> > I would love to hear what your ideas are on this...
> Same here...

Just a UI on top of PSML that is based on XSP.  The PSML would be
transformed into XHTML and would allow you to configure your own PSML
> > > You can do this now.  It just isn't implemented anywhere.  I think
> > > multiple customized pages is important.  IE I want an 'Open
> > > Source' and then a 'World News' page
> >
> > how? As much as I have understood, the PSML files are very _static_
> > currently... I cannot make "semi-personalized" pages, or can I?
> >
> > > The sitation should be a little different.  Mainly because of
> > > subscription support.  If someone comes from a WAP device and wants to
> > > create a customized page, Jetspeed needs to do some
> > > introspection to see
> > > which portlets the user can subscribe to (IE an HTML and WAP don't
> > > mix).
> No!!!! Cocoon will do it for you, that's the point!
> Cocoon will provide services for creating your site using components.
> JetSpeed should be a collection of components with some out-of-the-box
> glue to install them and see them working. But Cocoon should be the
> engine behind it that drives all the components in the right places at
> the right time.

ug.  NONE of this is implemented yet or even thought out!  Just because
I say Jetspeed will do this doesn't mean that Cocoon won't be used!

> > 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).
> Maybe on the jetspeed list, but I don't think you are a minority around
> here...

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

The goals are to move in this direction.  
> > But I'm still uneasy about putting in "dumb" CDATA sections... I would
> > rather leave this job totally to serializers. But I understand that this
> > wouldn't be possible if we want to support writing portlets with
> > webmacro for example.
> Of course, you loose something moving from Turbine into Cocoon, but what
> you gain is, IMO, worth the effort and the changes.

I don't like this ProjectX vs ProjectY format of this thread.

Jetspeed will ALWAYS run with Turbine and Cocoon.  We won't be getting
rid of either one for any time soon.  Each has its advantage.

Turbine handles the logic backend, Cocoon should handle the
presentation, Jetspeed should handle the data.  
> Again something that Cocoon already does with XInclude (or, at least,
> plans to do in the near future).
> 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 think you are viewing Turbine from the perspective of content.  The
Screens/Navigations etc can be done much better without code!  It should
be XML only.  I want to use Turbine for the backend features (database
pooling, etc)
> 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 :/

Yeah.  That would be me.  :) Read ./docs/TODO.  Cocoon 2.0 is great. 
But you don't see me talking about Jetspeed 1.3 all the time because the
code isn't done.  All these issues will be addressed.  



Kevin A Burton (
Message to SUN:  "Please Open Source Java!"
"For evil to win is for good men to do nothing."

View raw message