cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: Allow redirects inside error handling
Date Tue, 29 Apr 2003 14:13:20 GMT

Berin Loritsch wrote, On 29/04/2003 15.21:
> An error handler should do one thing: handle errors.
> It should not be complicated, or too dynamic.  If there is a 404 error,
> the user of the site needs to know one thing: the link was bad (they
> don't need a stack trace proving it).
> Is it good to customize the error pages?  Yes.  Error pages that look
> like they are part of the site are important.  Error pages that help
> the user get back on track (i.e. provide a link to a search function,
> a sitemap, and/or the main page) are necessary.
> When I see things that try to allow dynamic activity for error handling,
> it makes me wince.  There should be no actions, no redirects, no
> database access.  At the most, a simple generator/transformer/serializer
> chain.  That's it.

Actions are needed to make the developer access the error data 
programmatically and

> Anything more is FS.  By over-customizing the error handling logic you
> increase the chance of the error handling not reporting the right
> errors.

Well said. This is exactly my thinking.

Björn Lütkemeier wrote, On 29/04/2003 14.47:

 > As far as I see the problem with infinite loops does not only occur in
 > conjunction with error handling. Even with normal pipelines you are
 > able to
 > configure an infinite loop.

Error handling is *not* like normal sitemap logic. If it was so, we 
would have done <map:onerror redirect-to""/>. Instead we did another 
section. handle-errors should glob everything and be the *last* part of 
the chain.

 > The Java language does not prevent you from
 > implementing infinite loops.

So? This is for websites. Assembler can give you gotos... so?

 > Therefore I do not see any reason to allow
 > redirects anywhere in the sitemap, but forbid them in error handlers.

Show me why you really need them, when you can do the same in the Generator.

Carsten Ziegeler wrote, On 29/04/2003 14.43:

 > Ok, you are perhaps right that redirects in error handlers are not the
 > way to go for designing web apps. But, if someone decides to do so,
 > why should we create a barrior?


Cocoon is not Perl (yet ;-)

 > With the same arguments you could say we have to remove the redirect
 > from the pipelines as well etc.

I would like so, yes. And in fact were they not deprecated?
Besides, all logic of redirects should now go in the flowmap.

 > If someone wants to use redirects in an error handler, he should be
 > able to, but he must also live with the consequences and problems.

Why should he be able to? Can't he do a cocoon:// in the generator?
You see, it's very different. If you do it in the Generator, you are 
*including* outer comment in the handle errors. If you redirect, you get 
*out* of handle errors. From handle-errors, nobody should get out. ;->

 > And even without the explicit redirect-to, you can do a redirect using
 > an action, or using a reader or generator with the same url.

Exactly what I asked Sylvain to prevent. In my removal of the veto, it 
was included that Actions there should not be able to redirect there.

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

View raw message