Based on that ,one has three methods:
1. Use Multi Inheritance, which is both risky and dreadful, imho is too
easy to have side effects, still is the more clean solution described.
2. Use method_decorator, which is better if not that you have to wrap
every decorator function inside of it and are forced rewrite `dispatch`.
3. wrapping directly the `Klass.as_view()`, better but as documented it
seem more a problem than anything.
The advantage of the third method is that you preserve the logic of the
Classes, so that the same View can change, more or less slightly, it's
logic in different contexts.
I usually use solutions like this:
{{{
view = reduce(
lambda x, f: f(x),
(
third_decorator,
second_decorator,
first_decorator,
),
ViewKlass.as_view()
)
}}}
The good thing is that you can wrap group of common decorators in a single
iterable.
I don't know if it would be better to have a `django.utils` to do this or
just add to documentation this or some similar method.
--
Ticket URL: <https://code.djangoproject.com/ticket/25235>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Comment:
[https://groups.google.com/d/topic/django-
developers/gnctZWh0YsY/discussion django-developers discussion]. (For
future reference, it's usually better to wait until the mailing list
thread reaches a conclusion of what should be done before opening a
ticket.)
--
Ticket URL: <https://code.djangoproject.com/ticket/25235#comment:1>
* status: new => closed
* resolution: => wontfix
Comment:
Closing as #25146 seems to address this concern as discussed on the
mailing list.
--
Ticket URL: <https://code.djangoproject.com/ticket/25235#comment:2>