[PYTHON] How to use Decorator in Django and how to make it

background

I'm making a webapp with Django, but when I read the document on the Admin page, it seems that the following two codes can be replaced.

admin.py

from django.contrib import admin
from .models import Author

#No decorator
  class AuthorAdmin(admin.ModelAdmin):
    pass
  admin.site.register(Author, AuthorAdmin)

#With decorator
  @admin.register(Author)
  class AuthorAdmin(admin.ModelAdmin):
    pass

Well, I don't feel grateful if there is only one, but if there are dozens of admin.site.register (sth, sthAdmin) lined up, it's not easy on the eyes, so it's better to substitute this. I mean.

So what is a decorator! I thought, so I will investigate and summarize it within the range that I somehow understood.

The original article is here. It seems to be a topic of a system that can be understood and used only after the experience value has risen a little more. At least for me.

If you summarize only what you know first,

--If you define it on function or class, it will give you some effect. --For example, you can limit the execution of view to only logged-in users. --If you log or define a class, you can execute it without permission.

Well, it seems convenient, so I'll remember one by one each time it appears. Let's start.

Decorators are functions

Ignore the annoying concept of @ for now and compare the case with and without the Decorator.

example1.py

#With Decorator
  @login_required
  def my_view(request):
   return HttpResponse()


#No decorator
  def my_view(request):
   return HttpResponse

  my_view = login_required(my_view)

example2.py

#With Decorator
  @require_http_method(['GET','POST'])
  def my_view(request):
   return HttpResponse()


#No decorator
  def my_view(request):
   return HttpResponse()
  
  my_view = require_http_method(['GET'],['POST'])(my_view)
 

Without Decorator parameters

As you can see from the explanation so far, the decorator is just a function, it seems to take the function that follows as a parameter and take over the role. (Interpreted with this, there is no problem at present)

For example, when my_view (request) is called, it seems that it is actually equivalent to login_required (my_view) (request) being called.

One thing to note here is that Decorator is a type of design pattern when coding, not unique to python or Django.

So if you have some knowledge of python, you can make a decorator yourself. So, let's take a look at how to make a decorator little by little.

Introduction

Create an identity decorator. It doesn't do anything, it just takes a function and returns it. It's just the role of view in django.

example3.py

def identity(a_view):
  return a_view

In this case, the decorator above does the same job as my_view (request). Well, I'm still not sure. ..

Step 2

I decided to make a decorator that actually does some work. Let's try to make a decorator that logs the number of times the view is called.

example4.py

def log(a_view):
  def _wrapped_view(request, *args, **kwargs):
    logger.log('My view is called')
    return a_view(request, *args, **kwargs)
  return _wrapped_view

What I made here

――Take some kind of log --Return the view received by parametar as it is

What a simple decorator. The procedure to be executed is as follows.

• log(my_view)(request)
• _wrapped_view(request)
• my_view(request)

I don't know if it really makes sense, but it seems that I can log with this for the time being.

Next, add a feature to this decorator to see if the user trying to run wrapped_view is logged in.

example5.py

def login_required(a_view):
  def _wrapped_view(request, *args, **kwargs):
    if request.user.is_authenticated():
      return a_view(request, *args, **kwargs)
    return HttpResponseForbiden()
  return _wrapped_view

I'm not sure, but I wonder if my memory and comprehension are poor. ..