cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robin Green" <>
Subject Re: hoping for additional cocoon functionality
Date Mon, 18 Sep 2000 21:31:34 GMT
>From: fleur diana dragan <>
>Subject: hoping for additional cocoon functionality
>Date: 18 Sep 2000 13:40:36 -0400
>MIME-Version: 1.0
>Received: from [] by (3.2) with ESMTP id 
>MHotMailBB8F9DCF0047D82197EF3FD3910A0E310; Mon Sep 18 10:37:32 2000
>Received: (qmail 81940 invoked by uid 500); 18 Sep 2000 17:37:13 -0000
>Received: (qmail 81928 invoked from network); 18 Sep 2000 17:37:12 -0000
>From cocoon-dev-return-7690-greenrd Mon Sep 18 10:39:55 2000
>Mailing-List: contact; run by ezmlm
>Precedence: bulk
>X-No-Archive: yes
>list-help: <>
>list-unsubscribe: <>
>list-post: <>
>Delivered-To: mailing list
>X-Authentication-Warning: woodchuck: fleur set sender to 
>using -f
>X-Virus: Good Times

WTF!! :)

>Organization: Geek Not Goth
>Message-ID: <>
>Lines: 515
>User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.3
>X-Spam-Rating: 1.6.2 0/1000/N
>I've been playing with Cocoon1 for a few days, specifically to see if I
>can use Cocoon to do something specific so I don't have to write the
>whole damn app myself for work.
>Specifically, I need to be able to do XSL transforms on information that
>comes from the request (i.e. headers, cgi variables).  The formdata
>stuff appears to already be there via <xsl:param>, which is great.

The "standard" way to do this in Cocoon is with XSP instead of XSLT, either 
using taglibs or just straight Java code. See samples/xsp

Why do you want to use XSLT, may I ask?

>As a proof-of-concept, I wrote a Producer that takes the DOM tree of the
>requested file and adds a <request> element.  The xml file has a
><?cocoon-process type="xslt"?> directive.  It works nicely.  The
>attached patch file is my implementation.

That's probably fine - but don't call it ProducerFromRequest - that will 
cause too much confusion!! ProducerFromRequest was a Cocoon class that was 
removed for security reasons. Your class appears at first glance to be 
safer, since it wraps its input in a tag, preventing XSP attacks.

>This is obviously the wrong way to do it.  (I disabled caching since the
><request> object may change, which is so completely wrong, it makes me
>queasy, but hey, proof-of-concept, right?)

You don't need to turn off caching in When you return 
false from the hasChanged() method, no caching will be performed. See 
src/org/apache/cocoon/framework/ (maybe you knew that already 
but I just throught I'd point it out.)

Cocoon does caching against the URL and request parameters and user agent 
(see the source code for precise details) but since you have more info than 
that, you are in trouble, as regards caching.

Get Your Private, Free E-mail from MSN Hotmail at

Share information about yourself, create your own public profile at

View raw message