Django study notes - Class-Based-View

Preface

Everyone knows that learning Django is actually very simple, and you can get started with almost no effort. There is almost nothing difficult to understand about configuring a URL, assigning it to a function to process it, and returning a response.

After writing too much, some problems are gradually realized. For example, one view is relatively complex and calls many other functions. What should I do if I want to encapsulate these functions? Of course, you can use the comment #------view------ to isolate the function. This method is too low. It is simply deceiving yourself. It is not even encapsulated.

Python is an object-oriented programming language. If you only use functions for development, many object-oriented advantages will be missed (inheritance, encapsulation, polymorphism). So Django later added Class-Based-View. It allows us to write View using classes. The advantages of doing this are mainly the following two:

1. Improves the reusability of code, and you can use object-oriented technology, such as Mixin (multiple inheritance)

2. You can use different functions to handle different HTTP methods instead of judging by many ifs to improve code readability
   

##Use class-based views

#If we want to write a view that handles the GET method, it would be as follows when written using a function.

from django.http import HttpResponse
 
def my_view(request):
 if request.method == 'GET':
  # <view logic>
  return HttpResponse(&#39;result&#39;)

If written in class-based view, it would be as follows.

from django.http import HttpResponse
from django.views import View
 
class MyView(View):
 def get(self, request):
  # <view logic>
  return HttpResponse(&#39;result&#39;)

Django's url assigns a request to a callable function, not a class. To solve this problem, class-based view provides a

as_view()static method (that is, class method). Calling this method will create an instance of the class, and then call dispatch() through the instance. method, dispatch() method will call the corresponding method to process the request according to the different method of the request (such as get() , post() wait). At this point, these methods are almost the same as function-based views. They need to receive requests and get a response back. If the method is not defined, an HttpResponseNotAllowed exception will be thrown.

In the url, just write:

# urls.py
from django.conf.urls import url
from myapp.views import MyView
 
urlpatterns = [
 url(r'^about/$', MyView.as_view()),
]

The attributes of the class can be set in two ways, the first is the common Python Methods can be overridden by subclasses.

from django.http import HttpResponse
from django.views import View
 
class GreetingView(View):
 greeting = "Good Day"
 
 def get(self, request):
  return HttpResponse(self.greeting)
 
# You can override that in a subclass
 
class MorningGreetingView(GreetingView):
 greeting = "Morning to ya"

The second method, you can also specify the attributes of the class in the url:

Set the attributes of the class in the url Python

urlpatterns = [
 url(r'^about/$', GreetingView.as_view(greeting="G'day")),
]

Using Mixin

I think we need to understand django’s class-based -view (hereinafter referred to as cbv), first of all, you must understand the purpose of introducing cbv to django. Before Django 1.3, the generic view was the so-called universal view, which used function-based-view (fbv), which is a function-based view. Some people think that fbv is more pythonic than cbv, but they think otherwise. One of the important features of Python is object-oriented. And cbv can better reflect the object-oriented nature of Python. cbv implements view methods through classes. Compared with function, class can make better use of the specificity of polymorphism, so it is easier to abstract the more common functions within the project from a macro level. Regarding polymorphism, there is not much explanation. Interested students can Google it themselves. In short, it can be understood as one thing having multiple forms (characteristics). The implementation principle of cbv can be easily understood by looking at the source code of Django. Generally speaking, after the url is routed to this cbv, it is distributed through the dispatch method inside cbv, the get request is distributed to the cbv.get method for processing, and the post request is distributed to cbv. .post method processing, other methods are similar. How to use polymorphism? The concept of mixin is introduced in cbv. Mixin is just some basic classes that have been written, and then combined with different Mixins to become the final desired class.

So, the basis for understanding cbv is to understand Mixin. Mixins are used in Django to reuse code. A View Class can inherit multiple Mixins, but can only inherit one View (including subclasses of View). It is recommended to write View on the far right and multiple Mixins on the left. Mixin is also a relatively complex technology. I won’t go into details in this article. I will write an article about Mixin in the future.

Using decorators

In CBV, you can use method_decorator to decorate methods.

from django.contrib.auth.decorators import login_required
from django.utils.decorators import method_decorator
from django.views.generic import TemplateView
 
class ProtectedView(TemplateView):
 template_name = 'secret.html'
 
 @method_decorator(login_required)
 def dispatch(self, *args, **kwargs):
  return super(ProtectedView, self).dispatch(*args, **kwargs)

can also be written on the class and pass in the name of the method.

@method_decorator(login_required, name='dispatch')
class ProtectedView(TemplateView):
 template_name = 'secret.html'

If there are multiple decorators decorating a method, they can be written as a list. For example, the following two ways of writing are equivalent.

decorators = [never_cache, login_required]
 
@method_decorator(decorators, name='dispatch')
class ProtectedView(TemplateView):
 template_name = 'secret.html'
 
@method_decorator(never_cache, name='dispatch')
@method_decorator(login_required, name='dispatch')
class ProtectedView(TemplateView):
 template_name = 'secret.html'

For more articles related to Class-Based-View of Django study notes, please pay attention to the PHP Chinese website!