Home > Article > Backend Development > 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:
Improves the reusability of code, and you can use object-oriented technology, such as Mixin (multiple inheritance)
You can use different functions to handle different HTTP methods instead of judging by many ifs to improve code readability
##Use class-based views
from django.http import HttpResponse def my_view(request): if request.method == 'GET': # <view logic> return HttpResponse('result')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('result')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.
# 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
Using decorators
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'