From dev-return-61917-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org Fri Jun 04 14:52:42 2004
Return-Path: <dev-return-61917-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 65669 invoked from network); 4 Jun 2004 14:52:42 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur-2.apache.org with SMTP; 4 Jun 2004 14:52:41 -0000
Received: (qmail 2017 invoked by uid 500); 4 Jun 2004 14:52:00 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 1906 invoked by uid 500); 4 Jun 2004 14:51:58 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
list-post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 1765 invoked by uid 99); 4 Jun 2004 14:51:55 -0000
Received: from [192.55.208.20] (HELO mgate1.stjude.org) (192.55.208.20)
  by apache.org (qpsmtpd/0.27.1) with ESMTP; Fri, 04 Jun 2004 07:51:55 -0700
Message-ID: <1E0CC447E59C974CA5C7160D2A2854EC097E29@SJMEMXMB04.stjude.sjcrh.local>
From: "Hunsberger, Peter" <Peter.Hunsberger@STJUDE.ORG>
To: <dev@cocoon.apache.org>
Date: Fri, 4 Jun 2004 09:50:06 -0500
Subject: RE: error handling
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-OriginalArrivalTime: 04 Jun 2004 14:50:07.0490 (UTC) FILETIME=[3A517E20:01C44A43]
X-SEF-FD9E3BCC-24E9-4B6F-96E-FFC4B78-SJCRH: 1
content-class: urn:content-classes:message
Thread-Topic: error handling
Thread-Index: AcRKCbu/rLtNH29OTyyaTWNDZAWNEgANoAFQ
X-Virus-Checked: Checked
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

Torsten Curdt <tcurdt@vafer.org> writes:

<snip>sort of ugly solution</snip>

>=20
> > and specifying it in the called pipeline:
> > <map:pipeline handle-errors-for-internal-calls=3D"true"/>
>=20
> This looks much better
>=20
> > The names of the attributes/request-parameters I used have not been=20
> > set in the discussions. I just used here some to show the principle.
>=20
> :-)
>=20
> What about...
>=20
>    <map:pipeline handle-errors=3D"always|external|internal"/>
>=20
> our current behaviour would be "external".
> I would like to have "always" andt the
> "internal" option might be FS ;)

Hmmm, just wondering, if I have:

        <map:pipeline internal-only=3D"true">         =20

and I define a

           <map:handle-errors>

within it, would that now work? And if it did, would I have to specify
handle-errors=3D"internal" or would that be the default for such a
pipeline? =20

I realize, most people would likely only want a single handle-errors
section so that you don't have to specify the same error handling in two
different places. However, if someone did have a reason for having
different handling for the two cases I'd expect that they'd want to add
the handle-errors to the internal-only pipeline and not specify anything
else.  As such, handle-errors=3D"internal" does not seem necessary?

>=20
> > Now, implementing this should be a two or three liner :) I=20
> already had=20
> > it implemented but lost the code...
>=20
> You can also give me a hand ...up to you.
>=20
> cheers
> --
> Torsten
>=20
>=20