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
Description: Binary data
_______________________________________________ Repoze-dev mailing list Repozeemail@example.com http://lists.repoze.org/listinfo/repoze-dev