Package: django-universal-view-decorator
ContentsAbout Class Based View (CBV) decorationInstallationUsage@universal_view_decorator@universal_view_decorator_with_argsInheritanceAbout Class Based View (CBV) decorationIn django you can implement views in two different waysFBV (Function Based View)CBV (Class Based View)A project can make use of both techniques in parallel. While decorators work really well with FBVs, using them
with CBVs is a bit uglier. The django documentation recommends two techniques to decorate class based views:https://docs.djangoproject.com/en/1.9/topics/class-based-views/intro/#decorating-class-based-viewsDecorating in URLConf: applying the decorator to the view function returned by theView.as_view()class method.urlpatterns=[url(r'^my_view/',permission_required('my_app.my_permission')(MyView.as_view())),]I think this decoration technique is solid. It treats your view class as a view function and places the
decorator between the url config and the view function exactly as in case of decorating a FBV. The decorator
is guaranteed to execute before any methods in the decorated CBV.My only problem is that I have to do this in the URLConf module and on a per-url basis instead of being
able to apply the decorator onto the view class in the module in which it has been implemented.Applying your decorator to one of the methods of your view class (e.g.:dispatch()) with the help of@django.utils.decorators.method_decorator.classMyView(View):@method_decorator(permission_required('my_app.my_permission'))defdispatch(self,*args,**kwargs):returnsuper(MyView,self).dispatch(*args,**kwargs)# django 1.9+: this way you don't have to override dispatch() just to be able to decorate it@method_decorator(permission_required('my_app.my_permission'),name='dispatch')classMyView(View):...Problems with this solution:If someone subclasses the view and overrides the decorated method then the method override in the subclass is
executed before the decorator. The decorator can actually be bypassed completely by not calling the super
version of the overridden method. This may be a desired behavior sometimes but in case of some critical
(e.g.: permission) decorators it is a problem. In case of decorating in URLConf this isn’t a problem: in
that case the decorator is always executed before any view class methods.Minor issue: I have to write@method_decorator(permission_required('my_app.my_permission'))instead of
simply@permission_required('my_app.my_permission').As you see the two decoration techniques have different behavior. I find the behavior of technique #1 (URLConf
decoration) more useful and robust while cosmetically I prefer applying decorators to my view class implementations
as in case of technique #2 (@method_decorator).This library provides a@universal_view_decoratorhelper (similar to django’s@method_decorator) that combines
the behavior of decoration technique #1 with the cosmetics of technique #2:You can apply the decorator to the view class directly - you don’t have to mess with URLConf unless you want to
apply decorators on a per-url basis.Behaves like decoration method #1: under the hood it applies the decorator to the return value ofView.as_view()so it can’t be bypassed with subclassing.Besides the previously listed features@universal_view_decoratorprovides a bit more convenient interface than
django’s@method_decorator: after wrapping your view decorator with this helper you can apply it to FBVs, CBVs
and CBV methods with the exact same syntax. There is also a@universal_view_decorator_with_argsvariant of this
helper that comes in handy with view decorators that have parameters.Installationpipinstalldjango-universal-view-decoratorAlternatively you can download the distribution from the following places:https://pypi.python.org/pypi/django-universal-view-decorator#downloadshttps://github.com/pasztorpisti/django-universal-view-decorator/releasesUsage@universal_view_decoratorIf you wrap your view decorator with@universal_view_decoratorthen you can apply it to:FBVs (just like before wrapping it with@universal_view_decorator)CBVs (with the same behavior as in case of decoratingView.as_view()in URLConf)CBV methods (with the same behavior when applying your decorator to the view class method using django’s@method_decorator)fromdjango_universal_view_decoratorimportuniversal_view_decorator@universal_view_decorator(login_required)deffunction_based_view(request):...# You can wrap multiple decorators at the same time@universal_view_decorator(login_required,permission_required('my_app.my_permission'))deffunction_based_view(request):...# This double decoration is equivalent in behavior to the previous example# where we used one wrapper to wrap both legacy decorators.@universal_view_decorator(login_required)@universal_view_decorator(permission_required('my_app.my_permission'))deffunction_based_view(request):...# Applying the decorator to view classes. Behavior is the same as applying# the permission decorator to ``ClassBasedView.as_view()`` in the URLConf.@universal_view_decorator(permission_required('my_app.my_permission'))classClassBasedView(View):...# Applying the decorator to view class methods.# Behavior is equivalent to that of django's @method_decorator.classClassBasedView(View):@universal_view_decorator(login_required)defhead(self,request):...# Wrapping the decorator only once for reuse in our project:reusable_universal_login_required=universal_view_decorator(logic_required)@reusable_universal_login_requiredclassClassBasedView(View):...@universal_view_decorator_with_argsThe@universal_view_decorator_with_argsdecorator is pretty much the same as@universal_view_decoratorbut
it allows you to parametrize the wrapped decoratorafterwrapping it. This is very useful if you want to wrap
a decorator only once for reuse but the decorator has parameters that you don’t want to specify when you do the
wrapping:fromdjango_universal_view_decoratorimportuniversal_view_decorator,universal_view_decorator_with_args# with @universal_view_decorator you have to bind args before wrapping :-(my_permission_required=universal_view_decorator(permission_required('my_app.my_permission'))# we can specify args for permission_required when we apply the decorator :-)universal_permission_required=universal_view_decorator_with_args(permission_required)@universal_permission_required('my_app.my_permission')deffunction_based_view(request):...@universal_permission_required('my_app.my_permission')classClassBasedView(View):...classClassBasedView(View):@universal_permission_required('my_app.my_permission')defdispatch(self,request,*args,**kwargs):...InheritanceSubclasses of a decorated view class inherit the decorators. In the following exampleDerivedViewinherits a@login_requireddecorator from its base class:fromdjango_universal_view_decoratorimportuniversal_view_decorator@universal_view_decorator(login_required)classBaseView(View):...@universal_view_decorator(permission_required('my_app.my_permission'))classDerivedView(View):...The inherited base class decorators are applied first. The above example has the same effect onDerivedViewas decorating it in a URLConf like this:urlpatterns=[url(r'^derived_view/',permission_required('my_app.my_permission')(login_required(DerivedView.as_view()))),]