cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: [PROPOSAL] Extending Sitemap Error Handling
Date Wed, 10 Jul 2002 20:44:35 GMT
Sylvain Wallez wrote:
> Michael Melhem wrote:
>>> Currently, an implicit <map:generate type="!notifying-generator!"/> 
>>> is added as the first statement of <handle-errors> (see 
>>> HandleErrorsNode.invoke() in treeprocessor).
>>> What about making this explicit so we can choose other generators as 
>>> well, such as a standard file generator to display for example a nice 
>>> "page not found" page using some site-wide stylesheets ?
>>> <handle-errors>
>>> <match type="error" pattern="not-found">
>>>   <generate type="file" src="notfound.xml"/>
>>>   <transform src="skin/doc2html.xsl"/>
>>>   <serialize/>
>>> </match>
>>> <!-- fallback -->
>>> <generate type="notifying"/>
>>> <transform src="system/error2html.xsl"/>
>>> <serialize/>
>>> </handle-errors>
>> I like the idea of an explicit generator in the handle-errors...but 
>> doesnt this open up the sitemap handle-errors block for abuse?  
> What kind of abuse are you thinking of ?
>> 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...>


I remove my -1 on using custom Generators from handle-errors.

Hey, Sylvain, don't faint ;-P

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)
2 that redirects are completely banned from handle-errors.
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).

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

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).


Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

To unsubscribe, e-mail:
For additional commands, email:

View raw message