On 3/10/10 9:07 AM, Andrey Popp wrote:
>>> I was thinking of this too — it is good to return control back to
>>> application during handling of this kind of errors (4xx). Also it will
>>> convert notfound/forbidden views from special cases of Router
>>> processing cycle to special cases of "exception view".
>>>
>>
>> Right, I think it makes sense... do you think you might want to take a stab
>> at implementing that?
>
> Ok, what about reusing the current view registering/lookup machinery?
> I mean can we treat exception views as views for context defined by
> raised exception? So raising exception is just context switching
> inside request processing.
>
> Pros:
>
> * We can define different exception views for different request predicates.
> * Unification with view machinery.
>
> Cons:
>
> * We cannot access previously located context (if there was one),
> cause it replaced with current exception context.
> * We should register exception views for exception interfaces, not
> classes. This is because adapter lookup uses IRO, not standard MRO.
>
I think it should probably work like this:
- app developers should register views that match with a context that
equals the exception class itself, the default request type, and
the empty string as a view name.
- when bfg encounters any exception when calling a view (or trying to
resolve a root factory, etc.. basically the scope handled currently
when it catches NotFound/Forbidden), it will do this:
exc_view = registry.adapters.lookup((req_iface, providedBy(exc)), IView,
name='')
if exc_view is not None:
response = exc_view(exc, request)
The context of such an "exception view" will be the exception instance itself.
If you want a particular exception to be able to use a "real" context, you'll
make it available as an attribute of the exception for use by the registered
exception view (e.g. context.context or so).
--
Chris McDonough
Agendaless Consulting, Fredericksburg VA
The repoze.bfg Web Application Framework Book: http://bfg.repoze.org/book
_______________________________________________
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
