[PEAK] Sitemap driven error handling

[Phillip J. Eby]

At 05:30 PM 1/28/05 +0100, Radek Kanovsky wrote:
>On Thu, Jan 27, 2005 at 10:51:04AM -0500, Phillip J. Eby wrote:
>
> > It's a nice idea; I may not want to incorporate it into the current
> > version, though, as the error handling will become a generic function
> > at some point and thus the registration mechanism for it might be
> > quite different than for a view.
>
>I am voting for including some error handling configuration mechanism
>into sitemaps. Error handler registration is partly configuration act.
>Now we have .ini files and one or more sitemap.xml files in typical web
>application. Generic function predicates will become third configuration
>source. Controling error handler registration from sitemap is more
>convenient for me than writing predicates directly into .py files and
>dispersing configuration data to many sources.

Actually, sitemaps will be doing most of their configuration by adding 
generic function methods, for views, menus, and error handlers.  I don't 
intend to remove the convenience of sitemaps, they are a key part of the 
"user experience" for peak.web and will stay that way.  It's just *how* 
they do configuration that would change.  And, error handlers will likely 
not be registered in the same way as views, but it will be within a sitemap.

Note, by the way, that you can define your own XML namespace for use in 
sitemaps, allowing you to thereby create your own sitemap tags.  The 
mechanism for how those tags work is not well-documented yet, but you 
clearly have already looked deep into the sitemap module.  :)


>There is possibility to convert all exceptions to context-aware
>exceptions (as IWebExceptions are) by inspecting traceback and finding
>topmost TraversalContext on stack (probably imposible without touching
>traversing code). I have seen something similar in Python Cookbook but
>cannot find it now.
>
>I am currently using start context for non-IWebExceptions. That is
>the reason why handlers for non-IWebExceptions should be defined
>in root <location>.

When handle_http becomes a generic function, this magic will not be 
necessary, because there will be an "around" method to trap exceptions, and 
it will know the current publishing location.  It will not be able to 
identify the exact traversal location where the error occurred, but it 
*will* know the nearest publishing location (i.e. the nearest location in 
the published URL).