Return-Path: 
 <cocoon-dev-return-39670-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 12460 invoked by uid 500); 2 Apr 2003 15:29:23 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 12325 invoked from network); 2 Apr 2003 15:29:22 -0000
Received: from pop017pub.verizon.net (HELO pop017.verizon.net)
 (206.46.170.210)
  by daedalus.apache.org with SMTP; 2 Apr 2003 15:29:22 -0000
Received: from verizon.net ([139.85.116.117]) by pop017.verizon.net
          (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with ESMTP
          id <20030402152924.JHGZ1817.pop017.verizon.net@verizon.net>
          for <cocoon-dev@xml.apache.org>; Wed, 2 Apr 2003 09:29:24 -0600
Message-ID: <3E8B015B.50700@verizon.net>
Date: Wed, 02 Apr 2003 10:27:23 -0500
From: Vadim Gritsenko <vadim.gritsenko@verizon.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: Generators now allowed in <map:handle-errors>
References: <3E8A0606.2020206@anyware-tech.com> <3E8A2382.8070505@verizon.net>
 <3E8AA6F4.2020604@anyware-tech.com>
In-Reply-To: <3E8AA6F4.2020604@anyware-tech.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Authentication-Info: Submitted using SMTP AUTH at pop017.verizon.net from
 [139.85.116.117] at Wed, 2 Apr 2003 09:29:23 -0600
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

Sylvain Wallez wrote:
<snip/>

> Now from an implementation point of view, finding if a generator is 
> present by analyzing the sitemap is difficult, if not impossible, 
> since a generator can be inside a matcher/action/selector (will we go 
> in that path or not ?), or included in a resource also used in the 
> "normal" pipeline. Also, checking this at request processing time is 
> difficult, since the pipeline fails if a transformer is added when no 
> generator is present. 


AFAIR, in my version of the implementation of this feature (don't ask 
what happend to this implementation :-/ ), the way  to solve it was to 
extended and/or modify pipeline implementation so it uses "default" 
generator when no generator has been set. This extended / modified 
pipeline implementation can be instantiated from the error handler node 
of the treeprocessor, and provided with default generator "<notifier>".


Vadim