I've attached patch against trunk for that. It's also contain 5 new test cases.

On Mon, Mar 8, 2010 at 3:41 PM, Andrey Popp <8may...@gmail.com> wrote:
>> But features are *the enemy* of frameworks, so as the author I feel 
>> compelled to > provide a counterargument even if I don't really believe 
>> strongly in it. ;-)
> I like that repoze.bfg reuses webob for WSGI layer, but why not to
> reuse exceptions from that package? It is not about features, it is
> more about extending view API to allow raise exceptions from webob.exc
> (not all probably, but which are inherited from
> webob.exc.HTTPClientError). This is like view-lookup can raise
> NotFound and repoze.bfg.security — Forbidden.
>> In that spirit I'll note these things:
>> - you could use a decorator for the same purpose instead of relying on the
>> framework to do it for you.  It would be a pretty stupid decorator, but it
>> would work.
> I don't think it'll be stupid because it needs to catch HTTPException
> at initialzation, store it, when augment __call__ method and if the
> later was raised, it should reraise it during __call__ call.
>> - you could insert the webob.exc.HTTPExceptionMiddleware middleware into
>> your WSGI pipeline; this indeed converts webob exceptions to responses.
>>  This is another way of "extending the framework".
> It seems to be more better way than decorating each view, but it does
> not work, because there will be no INewResponse event fired and so on,
> even repoze.bfg.exceptions.NotFound and webob.exc.HTTPNotFound will
> not be semantically equal. That is not a good thing.
> Thanks.

Andrey Popp

phone: +7 911 740 24 91
e-mail: 8may...@gmail.com

Attachment: webob_exc.patch
Description: Binary data

Repoze-dev mailing list

Reply via email to