#1840: admin/doc/views shows decorator instead of actual view function
-----------------------------------+----------------------------------------
Reporter: [EMAIL PROTECTED] | Owner: adrian
Type: defect | Status: new
Priority: low | Milestone:
Component: Admin interface | Version:
Severity: minor | Resolution:
Keywords: |
-----------------------------------+----------------------------------------
Comment (by lukeplant):
Adrian -- the {{{__doc__}}}, {{{__name__}}} and {{{__module__}}}
assignments should be fine. I was using the 'decorator' module, which
does that for you and also creates 'signature preserving' decorators, so
you can use getargspec etc on them. However, I've just discovered that I
was using it incorrectly, and using it correctly works very well.
The advantages of using the module are:
* You don't have to repeat the {{{__doc__}}}, {{{__name__}}} etc
assignments (although I guess you could put them in a utility function)
* You preserve the signature of the original functions, so you can
introspect them.
The disadvantages are:
* Adding more code to Django (120 lines, which includes doctests)
* The changes you have to make are not quite as trivial as I thought
before -- I thought it was just adding {{{ staff_member_required =
decorator(staff_member_required }}}. In reality, you have to change the
decorator function like this:
{{{
#!python
def staff_member_required(view_func):
def _wrapped(request, *args **kwargs):
# Do stuff with request
return view_func(request, *args, **kwargs)
}}}
to
{{{
#!python
@decorator.decorator
def staff_member_required(view_func, request, *args, **kwargs):
# Do stuff with request
return view_func(request, *args, **kwargs)
}}}
The transformation is very straightforward in each case -- write a
'caller' (which takes a function and the arguments to pass to it) instead
of a typical decorator, and then use 'decorator' to make it into a very
well-behaved decorator. In some sense it is a simplification -- you have
a simple higher order function instead of higher order function plus
closure. On the other hand, it is a slight obfuscation, since
staff_member_required() looks like it takes several arguments, but it ends
up as a callable that takes a single argument.
Overall I think I'm in favour of using it -- it would also solve the
problem that Gary Wilson just mentioned in django-devs about not being
able to use decorators with filters.
--
Ticket URL: <http://code.djangoproject.com/ticket/1840>
Django <http://code.djangoproject.org/>
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
-~----------~----~----~----~------~----~------~--~---
