cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Unico Hommes <>
Subject Re: [RT] Forwarding of internal pipeline calls
Date Mon, 08 Mar 2004 11:21:49 GMT
Carsten Ziegeler wrote:

>While using internal cocoon redirects, I found out that there are
>potential problems with error handling (it might be that we have
>discusses this already...).
>Now, if you do a:
><map:redirect-to uri="cocoon://something"/>
>than this is an internal pipeline call (and not a new http request).
>This has of course some advantages (e.g. performance etc), but
>has imho the drawback that in this case, the error handling
>of the calling pipeline is *always* used. This means if an error
>occurs while processing the "something" pipeline, the error
>handler of the pipeline containing the redirect-to is invoked.
>Now, in general this might be a good solution for internal pipeline
>calls when they are used in a map:generate etc., but it's imho
>a little unusal for a redirect.
>We had recently the discussion on this list, if we need a general
>solution to specify which error handler is used for internal pipeline
>calls. I discussed this a little bit with Vadim on IRC during our
>first friday and he suggest to specify this not on the caller but
>on the called pipeline. So the map:pipeline containing the
>"something" pipeline specifies what to do. Regardless if this is
>the better choice than specifying it in the uri ("cocoon:...."),
>it's technically nearly impossible. When the internal pipeline
>is called, everything happens outside the treehandler and there is
>no real chance to get the error handler etc. (Of course we could
>change something here and there and then it will work.)
>So, I just tried the other way:
><map:redirect-to uri="cocoon://something?cocoon:forward=true"/>
>The current implementation I have can only be used for redirects,
>although it's fairly simple to extend it to be used in
>map:generate etc. as well.
>WDYT? Is this of general interest?
I am just thinking whether it'd be worth a separate protocol something 
like forward://something ?


View raw message