I really like the idea of implementing this as a url pattern decorator.
This seems similar to Alex Gaynor's talk about everything being a view.
It's more flexible than a middleware because you can decorate any part of
the urls tree, such as the patterns for a single reusable app.
urls = decorate_recursively(login_required, patterns(...))
This is actually possible to implement today, see snippets like
https://djangosnippets.org/snippets/2532/. The code required is kind of
ugly, so I think it would benefit from an implementation in core.
On Thu, Oct 17, 2013 at 12:19 AM, Anssi Kääriäinen
<[email protected]>wrote:
> 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 a topic in the
> Google Groups "Django developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/4TnXsONNEso/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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.
>
--
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/CACPudh1xghzzyOHKcgz8fawFzWEJunLu6AAbJfBYgCdH1tBkHg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
