#14512: Documentation & tools for decorating class-based-views.
---------------------------------------+-----------------------------------
Reporter: lrekucki | Owner: lrekucki
Type: New feature | Status: reopened
Milestone: 1.4 | Component: Generic views
Version: SVN | Severity: Normal
Resolution: | Keywords: class-based-views
Triage Stage: Accepted | Has patch: 1
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
---------------------------------------+-----------------------------------
Comment (by dstufft):
I for one think this is the wrong way of allowing someone to add something
like requiring login to a class based view.
For one
{{{
#!python
@view_decorator(login_required)
class ProtectedView(TemplateView):
template_name = 'secret.html'
}}}
Is ugly and janky. requiring a @view_decorator makes CBV's uglier and a
second class citizen decorator wise because of legacy code. Using a
decorator I would also argue is the wrong approach. There is already a
well tested, backwards compatible (with regards to python), and language
agnostic method of changing the behavior of a classes methods.
{{{
#!python
class ProtectedView(LoginRequired, TemplateView):
template_name = 'secret.html'
}}}
You can make a Mixin backwards compatible with function based views easily
enough, and this puts all the information about where the functionality of
a particular view is coming from (in the definition of the class, where it
belongs in my opinion). Which is all you are really doing with your
view_decorator approach, you are just hiding the fact you are mixing in
functionality by using a decorator and dynamically subclassing and mixing
in.
Additionally using a Mixin makes it easy to break the (now) decorators
into multiple methods and allow the end user to easily modify a portion of
it to fit their view. Currently with function based decorators this isn't
possible, it's all or nothing. You can solve this problem by making class
based decorators (which is sort of a Mixin anyways), but then you are
adding even more code just so you can add a mixin via @ instead of the
normal method of mixing in. An example use case of this is the guy who
recently on the mailing list wanted login_required to check is_active.
Currently his only option is to rewrite the login_required decorator.
--
Ticket URL: <https://code.djangoproject.com/ticket/14512#comment:17>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
