On Wednesday, October 16, 2013 8:36:05 PM UTC+3, Shai Berger wrote:

> I think the middlewares have grown a little complicated, and I'd try to 
> avoid 
> adding functionality there. That said, the feature of universal decoration 
> seems like it is worthwhile. I'd try to see if it can be added through the 
> urls mechanism instead -- you'd get behavior that is more like a 
> decorator, in 
> the sense that decoration would happen only once. 
>

I hacked together a branch where middlewares could define wrap_request and 
wrap_view methods in addition to all existing process_* methods. The 
wrap_request and wrap_view methods are call-through. It turns out that it 
will be impossible to both bubble up exceptions through wrap_* methods 
while also supporting current middleware semantics. Currently exceptions 
get converted immediately to 500 responses. Doing that and also raising the 
exception through the stack is obviously impossible.

Allowing view wrapping in urls.py seems like a good solution. It would 
allow for what ATOMIC_REQUESTS does currently. And more - it would allow 
wrapping just part of your views, not all of them. Having the ability to 
apply permission_required to a collection of views from urls.py seems like 
a nice feature.

That still leaves whole request wrapping into impossible to achieve state. 
Maybe guarantee that all process_response methods are ran even if some of 
the raise exceptions is enough?

Currently there is no guarantee that all process_response methods get 
called. It seems that support for that would be fairly small backwards 
incompatible change. See: 
https://github.com/akaariai/django/commit/cc459994bb7899e744471dcb7ec034e6e1c310af.
 
This would add a guarantee that if process_request is called, then matching 
process_response gets called, too. Notable there is still no guarantee that 
if process_response is called, then process_request was also called. But 
changing that isn't easy to do.

 - Anssi

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/98bd7629-38f1-409e-b2c1-1a058ed3559e%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to