> 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. _______________________________________________ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
