Return-Path: 
 <cocoon-dev-return-29329-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 30212 invoked by uid 500); 11 Jul 2002 08:29:26 -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 30201 invoked from network); 11 Jul 2002 08:29:25 -0000
Message-ID: <3D2D4213.2050402@anyware-tech.com>
Date: Thu, 11 Jul 2002 10:30:11 +0200
From: Sylvain Wallez <sylvain.wallez@anyware-tech.com>
Organization: Anyware Technologies
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.0rc2) Gecko/20020510
X-Accept-Language: fr, en
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [PROPOSAL] Extending Sitemap Error Handling
References: 
 <Pine.LNX.4.43.0207101244150.5098-100000@fztig938.bank.dresdner.net>
 <3D2C2BF9.50907@anyware-tech.com> <3D2C377A.7000605@apache.org>
 <3D2C477A.9090306@anyware-tech.com> <3D2C4E48.1080909@apache.org>
 <3D2C5874.2020009@anyware-tech.com>
 <20020710163139.GC27684@fztig938.bank.dresdner.net>
 <3D2C6563.6040007@anyware-tech.com> <3D2C9CB3.9090509@apache.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

Nicola Ken Barozzi wrote:

> Sylvain Wallez wrote:
>

<snip/>

>>> Wouldnt the ability to have custom handle-errors generators make it 
>>> more likely that the handle-errors pipe would throw the very 
>>> error/exception thats its trying to handle..and wouldnt this cause 
>>> an infinate loop?
>>
>>
>> No risk of infinite loops, as exceptions occuring inside a 
>> <handle-errors> aren't processed again by the sitemap. Also, not only 
>> generators can throw exceptions, but also matchers, transformers, 
>> actions, etc. which are allowed in handle-errors.
>
>
> Sylvain, you know what?
> You're right :-)
>
> A generator can fail in handle-errors with no real problem, if not 
> that the error is then processed by the servlet, as with any other 
> failing component in that part of pipeline.
>
> The only thing that has to be avoided is redirects.
>
> As for having different DTDs, it's not a problem, since users will 
> presumably use the supplied Generator for notifications, and also 
> error handling pipelines are usually very simple.
>
> Sylvain, now listen to me.
> Sit down, and stay calm...
>
> <drums rolling...>
>
> TADA!
>
> I remove my -1 on using custom Generators from handle-errors.
>
> Hey, Sylvain, don't faint ;-P


Woohoo ! No, I didn't faint, as I was prepared by the drums !
ROFL ;)

> Yes, for me it's +0 to enable generators in handle-errors, given that
> 1 there are no -1s for this (I'm not sure I was the only one) 


HEY, SOMEONE ELSE ?

> 2 that redirects are completely banned from handle-errors. 


Can be checked.

> 3 that the NotifyingGenerator simply notifies what is given in a 
> well-known and public key of the Context (rather than hidden), that it 
> fails gracefully if not present (outputs an empty notification), and 
> that it's called automatically if not defined (backwards compatibility).


You mean "object model" and not "context", right ? Currently, the 
NotifyingGenerator throws a ProcessingException if there is no Notifying 
in the object model, and IMO it's wiser than silently generating an 
empty notification. Don't you think so ?

To ensure maximum backward compatibility with the current implicit 
generator, and considering that we deprecate the "type" attribute on 
handle-errors, I propose to require an explicit generator for 
handle-errors _without_ the "type" attribute and keep the current 
implicit generator for handle-errors _with_ this attribute.

The effect is that current sitemaps that have a "type-less" 
handle-errors can be ported by simply adding a type="500". An adequate 
error message will help people to migrate smoothly.

> This way users can use it to just notify things directly from actions 
> if needed, even if they are not errors.


Yes, this will finally allow a wider usage of the notification stuff.

> After/if you do the change, I will see what can be done to nuke the 
> Builder someway if better (seems so now, just need to check).


Why do you want to nuke it ? We just need to add configuration stuff to 
have some meaningful getType().

As for doing the change, Vadim reminded us there are some bugs to 
correct, and I still have my paid-work to do :-/ I should have some time 
for Cocoon development bu the end of the month and in august.

So if nobody objects, let's add this to the todo list for 2.1.

Sylvain

-- 
Sylvain Wallez
  Anyware Technologies                  Apache Cocoon
  http://www.anyware-tech.com           mailto:sylvain@apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org