To solve this problem, class based views was born. Therefore, Django now has two views based on function or class.
Change site function view to class view
URL and view relationships
Generally, first open the browser, then enter a web address, that is, the URL, in the address bar of the browser, and then press enter. We can see the content returned by this web address in the browser. This is a process that we can see. There are also some processes that we can’t see. That is, when we enter the URL in the browser, press enter, and then the browser will send an HTTP request to the target URL. After receiving the request, the server will respond to the request. This response is to render the corresponding content through the browser and present it to us.
This process is the request and response:
The browser sends a request to the server. The server processes the request, returns the HTTP response, and finally returns the HTML document to the front end
The expression is as follows:
urlpatterns = [
Parameter description in brackets:
1. A regular expression string
2. A callable object, usually a view function or a string specifying the path of the view function
3. Optional default parameters to be passed to the view function (dictionary form)
4. An optional name parameter (alias)
For example, I want to construct three URLs, the home page of the website（http://www.django.cn/ ）, news（ http://www.django.cn/news/ ）Forum（ http://www.django.cn/bbs/ ）, we can do this。
urlpatterns = [
This is how the URL is constructed. Our domain name is www.django Cn does not need to be written. The complete URL should be written as follows: path (regular expression, views view function, parameter, alias), the regular expression and views view function in it must be written, and the parameter and alias are optional. We only write when we have special needs. For detailed introduction and usage of URLs, please refer to the article: route configuration system urlconf
We can see from the above that each URL corresponds to a view function name. The view function name cannot be the same, otherwise an error will be reported. View function, the view Py file. Then in urls Py file is imported in the following way:
From app application name import views
From app application name VEWS import function name or class name
The view function is a simple Python function that accepts a web request and returns a Web response. The response can be HTML content of a web page, a redirect, a 404 error, an XML document, or a picture Anything is OK. No matter what logic the view itself contains, a response should be returned. The general convention for this view function code is to place it in the project or application directory called views Py.
Two core objects are generated in the HTTP request:
1. HTTP request —->httprequest object, all information related to user request (object)
2. HTTP response —->httpresponse object, response string
We have operated once before in the welcome page chapter. Let’s review:
First, open the views Py file, write a hello view function, and enter:
from django. http import HttpResponse
After the code is written, the startup project can see the string returned by the view function “welcome to Django” in the browser
Each URL corresponds to a view function. When a user requests to access a page of the Django site, the Django routing system (URL configuration file) decides which view function to execute and which algorithm to use.
Through URL correspondence matching – > find corresponding function (or class) – > return string (or return rendered string after reading HTML), this process is the life cycle of our Django request.
View functions are performed around two objects, httprequest and httpresponse.
Differences between class view and function view
Views defined in the form of functions are called function views, which are easy to understand. However, when the path corresponding to a view provides support for many different HTTP request modes, you need to write different business logic in a function, and the code readability and reusability are poor.
For example, the function view used in my previous website:
from django. shortcuts import render
But later, when writing comments, logging in and other functions, I felt that the business logic was very messy, and I was eager to improve the functions of the website as soon as possible, so I couldn’t figure out how to move forward for a few days. It may also be that when I first wrote, I didn’t think so far. Later, it became more and more complicated. I also felt the convenience of class view in the future opening. So I changed to the class view:
Except for the functions used by individual websites, the main body of the basic website has been changed to the class view.
They are also different in the configuration of rul:
Normal view function:
from .views import index urlpatterns = [ url(r'^index/$', index, name='index'),]
Generic class view:
from .views import ClassListView urlpatterns = [ url(r'^index/$', ClassListView.as_view(), name='index'),]
When using functional graphs, you need to define multiple views that can be used
from xx import xx as x1This avoids duplication of views
For example, in the model, you can write a get to the class_ The ordering function then sorts according to the parameters given by the front end.
In the previous interface, because the back-end functionality is too little, the calculation in the front-end is also very cumbersome.
Anyway, when I developed the comment function, it was a mess.
- The class view is more repeatable than the function view. When using the function view, you always feel that there is only one render interface. As a result, the business logic relationship is very complex after the website becomes more complex.
Finally, thank youtendcodeHelp and answers for..
This work adoptsCC agreement, reprint must indicate the author and the link to this article