cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Cocoon and Jetspeed
Date Tue, 30 May 2000 23:19:15 GMT
Neeme Praks wrote:
> > -----Original Message-----
> > From: burtonator []
> > Sent: Tuesday, May 30, 2000 10:11 PM
> >
> > How is Xinclude support in Xerces?  I haven't tested it yet.
> neither have I ;-(

XInclude is _not_ supported in Xerces. Donald wrote a processor/filter
for both Cocoon1 and Cocoon2 that implements this.

> but Xinclude has been up in the air on this list for quite some time
> already, so I think it must be supported somehow ;-)

It is.
> > 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.

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.

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.

Which would also allow us to understand where we can improve the
> 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.
> > The real benefit of this proposal would be to store the PSML in the
> > database.  This is something that is very important.  The
> > problem is the
> > ideal situation hasn't come up yet.  I am trying to come up with the
> > "official" Jetspeed database/XML persistence mechanism (which would be
> > up for vote) but just haven't had time.  Right now there are a lot of
> > different solutions but they all don't tie together correctly (Ozone,
> > Castor, OPaL, BasePeer, EJB, XML, XML Schema).  There is a huge amount
> > of technical overlap in all these areas.  Each has their
> > advantages and
> > disadvantages and I want to come up with an official proposal that
> > leverages all the advantages with none of the disadvantages.  For
> > example Ozone has really nice XML persistence but its datastore isn't
> > portable (IE you always use the Ozone datastore) but with
> > Castor/OPaL/BasePeer you get a portable database but you don't get the
> > nice, rich XML support without a lot of work.  The blend of the two is
> > 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.

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.

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

By simply _using_ Cocoon, so being upstream, you have to do all that
stuff yourself, you have to clone something that is already implemented
and with lot of care, I might add.

You are usually the one that suggests eating our own dog food. I go even
further: share the same table, while doing so!
> 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?

> 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.
> So, the registry would store metadata about the portlet: where to find
> and how to access the portlet and what media types does it support. Then
> I would be up to the portlet developer to actually implement the support
> for these media types.
> > The above would only work for Cocoon portlets.  I don't want
> > a situation
> > where we require Cocoon.  Some people might not ever care
> > about Cocoon.

It's the same situation of servlets: people sure don't care about JServ,
they just want the servlet output.

> > IE the Jetspeed Admin console doesn't use Cocoon because if Cocoon
> > breaks you can't use the Admin console to fix it :)
> But don't you think that Turbine framework, in its current form (being
> _very_ ECS friendly), is a little bit limiting to Jetpseed?
> I mean, if I want to return SAX events instead of ECS element, how can I
> achieve that?

Well, currently this is not a problem because is JetSpeed that calls
Cocoon, not the other way around. 
> I would even go as far as requiring Cocoon, as I'm very fond of the
> power of XML technologies and I think they give you enormous amount of
> power for the cost of some added complexity... 


> I find this power really
> worth the complexity but I understand that I could be a minority here...

Maybe on the jetspeed list, but I don't think you are a minority around

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

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.
> > > The border tag would specify the preferred way (specified by portlet
> > > developer) how the "border" of the portlet would be
> > rendered. The user
> > > could override these settings with some system-wide theme for border
> > > rendering. The content tag would include the XML content of
> > the portlet
> > > as well as stylesheets for transformation of this content
> > to appropriate
> > > client.
> >
> > We also need a better way to represent the rendered Portlets and their
> > HTML.  But I think this should be done with CDATA sections withing
> > portlet markup and then XSLT this into an XHTML document with Cocoon.
> yep. I was also thinking about the CDATA option... but then I tought
> that I couldn't do a device dependent transformation on this afterwards.
> But if we would to this transformation before (in a device dependent
> way), then it should be ok.
> 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.
> But who says that this CDATA is actually XHTML? There is really no way
> to check that...

Exactly. This is the kind of hacks you have to do while _using_ cocoon
and not let it handle content as it knows.
> I also had the idea about the overall page rendering that would also be
> implemented with similar approach. Currently it is very hardcoded, I
> even found some ECS stuff there... I understand that it is still very
> raw and it is going to be rewritten, so here is my idea for that.
> The page coul bacically be something like this:
> <portalpage>
>     <portlet>
>     </portlet>
>     <portlet>
>     </portlet>
> </portalpage>
> Each of the portlets would also include hints about the rendering and
> XSLT would take care of the actual conversion, replacing the need for
> "controllers" in the current sense. Does this make sense?

The sitemap should be the controller. Each JetSpeed page should contain
only semantics that drive the pipeline components to generate final
rendering based on request state.
> > > The use of this kind of system would also enable the possible use of
> > > "remote portlets": XML pages (that follow the portlet DTD)
> > residing on
> > > remote server that could be rendered as portlets on local server...
> >
> > Hm.. That is interesting.  Performance would be an issue.  What
> > advantages would this give?
> Jetspeed could cache this (if it is cacheable), otherwise it would be
> highly recommended to put this on some server with _fast_ connection to
> the Jetspeed server. The benefit would be the possibility to distribute
> the workload from one side. From the other side, user could code up his
> own portlet on his homepage and then add this to his personal page...
> Truly personalized content.

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 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

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 :/

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------

View raw message