本節內容: 一、Django簡單示例 二、MTV之url控制器 三、MTV之視圖函數 四、MTV之模板 1、Django的簡單示例 一、須要知道的一些關鍵點 1 Django項目不管多大,只是一個應用程序 2 地址欄發請求默認是:一、GET請求 二、form表單能夠發送get請求,也能夠發送post請求 三、
標籤也能夠發送請求 3 瀏覽器接受的響應體是字符串,由瀏覽器解釋渲染成頁面給用戶看 4 form表單的提交按鈕事件: 給action對應的服務器發送請求 '' GET /auth/?數據user=yuan&pwd=123 .... ...... ...... 空行 請求體 # user=yuan&pwd=123 '' 5 新的響應會覆蓋以前請求的響應頁面 二、Django的簡單示例 寫代碼的順序就按文件的順序 urls.py代碼 from django.contrib import admin from django.urls import path,re_path from app01 import views # 引入視圖模塊 urlpatterns = [ path('admin/', admin.site.urls), path('index/', views.index), path('login/', views.login), ] PythonCopy views.py代碼示例 from django.shortcuts import render,HttpResponse,redirect # 響應體三劍客 # Create your views here. def login(request): if request.method=="GET": return render(request,"login.html") else: # request :包含全部請求信息 # 獲取請求信息 print("body", request.body) # 請求體原生數據 print(request.method) # "POST" 請求方式 print(request.path) # "/auth/" 拿到路徑 print(request.GET) #
print(request.POST) #
user = request.POST.get("user") pwd = request.POST.get("pwd") print("user", user) if user == "alex" and pwd == "123": return redirect("/index/") # 這樣這裏寫死了代碼 return HttpResponse("Error!") PythonCopy login.html代碼示例
Title
HTMLCopy 2、路由控制器 本質是URL與要爲該URL調用的視圖函數之間的映射表,就是以這種方式告訴Django, 對於客戶端發來的某個URL調用哪一段邏輯代碼對應執行。 (這裏注意使用反向解析,能夠實現動態修改訪問路徑) 這裏的執行順序: 一、拿着path(路徑:IP地址或域名,以後的,?號以前的,這中間這一截,/index/), 二、在urls.py的urlpatterns的列表中進行比對,比對成功 三、執行對應的視圖函數, 四、視圖函數返回響應給瀏覽器 一、簡單的使用 相應代碼示例 urls.py文件 from django.urls import path,re_path from app01 import views urlpatterns = [ # 從上往下匹配,(先後條件均可以匹配成功的話)若是前面的先匹配,後面的就不會再匹配, re_path(r'^articles/2003/$', views.special_case_2003), # special_case_2003(request) re_path(r'^articles/([0-9]{4})/$', views.year_archive), # year_archive(request,1999) re_path(r'^articles/([0-9]{4})/([0-9]{2})/$', views.month_archive), re_path(r'^articles/([0-9]{4})/([0-9]{2})/([0-9]+)/$', views.article_detail), ] 相應的解釋: /articles/2005/03/ 請求將匹配列表中的第三個模式。Django 將調用函數views.month_archive(request, '2005', '03')。 /articles/2005/3/ 不匹配任何URL 模式,由於列表中的第三個模式要求月份應該是兩個數字。 /articles/2003/ 將匹配列表中的第一個模式不是第二個,由於模式按順序匹配,第一個會首先測試是否匹配。 請像這樣自由插入一些特殊的狀況來探測匹配的次序。 /articles/2003 不匹配任何一個模式,由於每一個模式要求URL 以一個反斜線結尾。 /articles/2003/03/03/ 將匹配最後一個模式。Django 將調用函數views.article_detail(request, '2003', '03', '03')。 PythonCopy 注意: 一、若要從URL 中捕獲一個值,只須要在它周圍放置一對圓括號。 二、不須要添加一個前導的反斜槓,由於每一個URL 都有。 例如,應該是^articles 而不是 ^/articles。 三、每一個正則表達式前面的'r' 是可選的可是建議加上。 它告訴Python 這個字符串是「原始的」 —— 字符串中任何字符都不該該轉義 二、分組(目的:傳參給view函數) 上面的示例使用簡單的、沒有命名的正則表達式組(經過圓括號) 來捕獲URL 中的值並以位置 參數傳遞給視圖。 在更高級的用法中,可使用命名的正則表達式組來捕獲URL 中的值並以關鍵字 參數傳遞給視圖。 在Python 正則表達式中,(這個是1版本的寫法,2版本默認有首尾的正則限定,不用寫) 命名正則表達式組的語法是(?P
pattern), 其中name 是組的名稱,pattern 是要匹配的模式 fe:命名分組的寫法 下面是以URLconf 使用命名組的重寫: urls.py文件 from django.urls import path,re_path from app01 import views urlpatterns = [ re_path(r'^articles/2003/$', views.special_case_2003), re_path(r'^articles/(?P
[0-9]{4})/$', views.year_archive), re_path(r'^articles/(?P
[0-9]{4})/(?P
[0-9]{2})/$', views.month_archive), re_path(r'^articles/(?P
[0-9]{4})/(?P
[0-9]{2})/(?P
[0-9]{2})/$', views.article_detail), ] 這個實現與前面的示例徹底相同,只有一個細微的差異: 捕獲的值做爲關鍵字參數而不是位置參數傳遞給視圖函數。例如: 詳細解釋: /articles/2005/03/ 請求將調用views.month_archive(request, year='2005', month='03')函數, 而不是views.month_archive(request, '2005', '03')。 /articles/2003/03/03/ 請求將調用函數views.article_detail(request, year='2003', month='03', day='03')。 在實際應用中,這意味你的URLconf 會更加明晰且不容易產生參數順序問題的錯誤 —— 你能夠在你的視圖函數定義中從新安排參數的順序。固然,這些好處是以簡潔爲代價; PythonCopy 三、分發(目的:解耦合) 不是把全部的urls都寫在全局的urls.py文件中, 而是在全局的urls.py指向對應的app文件中的urls.py文件中, 在對應的app中作進一步的分發,從而達到了各個app的在全局的urls文件的解耦 # 全局的urls.py文件 urlpatterns = [ path('admin/', admin.site.urls), # 分發 url('app/', include('app.urls')), # 分發指向具體的app下,達到解耦 url('app02/', include('app02.urls')) ] # app01下的urls.py urlpatterns = [ url(r'^articles/2003/$', views.special_case_2003), # special_case_2003(request) ] # app02下的urls.py urlpatterns = [ url(r'^videos/(\d+)', views.videos), # special_case_2003(request) ] PythonCopy 四、反向解析 目的:動態的改變path路徑,從而避免硬編碼這些URL, 直白的說:改變原來的path,就要手動改把全部文件中有關於的這path的名字。 在使用Django 項目時,一個常見的需求是得到URL 的最終形式, 以用於嵌入到生成的內容中(視圖中和顯示給用戶的URL等)或者用於處理服務器端的導航(重定向等)。 一、在須要url的地方,咱們第一時間考慮url反查 在須要URL 的地方,對於不一樣層級,Django 提供不一樣的工具用於URL 反查: 一、在模板中:使用url 模板標籤。 二、在Python 代碼中:使用from django.urls import reverse()函數 兩種代碼及解釋示例 urls.py文件 from app01 import views urlpatterns = [ path('admin/', admin.site.urls), path('home/', views.index,name="index"), # 反向解析,動態的給view函數輸入path path('login.html/', views.login,name="Log"), # 反向解析,動態的給HTML的form表單,輸入重寫path ] views.py文件 from django.shortcuts import render,HttpResponse,redirect # Create your views here. from django.urls import reverse def login(request): _url=reverse("index") # 該命令是是動態的接收反向解析的path print("_url",_url) return redirect(_url) login.html文件
命名url: 不能夠跟其餘應用中的名稱衝突; 在URL 名稱中加上一個前綴,好比應用的名稱,將減小衝突的可能。 建議使用myapp-comment 而不是comment。 PythonCopy 3、MTV之視圖函數(Django的視圖層) 一個視圖函數,簡稱視圖,是一個簡單的Python 函數,它接受Web請求而且返回Web響應。 響應能夠是一張網頁的HTML內容,一個重定向,一個404錯誤,一個XML文檔, 或者一張圖片. . . 是任何東西均可以。 不管視圖自己包含什麼邏輯,都要返回響應。 代碼寫在哪裏也無所謂,只要它在你的Python目錄下面。 除此以外沒有更多的要求了——能夠說「沒有什麼神奇的地方」。 爲了將代碼放在某處,(全部的視圖函數約定放在這個文件下) 約定是將視圖放置在項目或應用程序目錄中的名爲views.py的文件中。 一、視圖函數的介紹 視圖層,熟練掌握兩個對象便可:請求對象(request)和響應對象(HttpResponse) 代碼介紹解釋 from django.shortcuts import render,HttpResponse,redirect # 響應體三劍客 # Create your views here. def index(request): # 響應體:HttpResponse render redirect # Django響應必定是HttpResponse類對象 #return HttpResponse("
INDEX
") good_list=['小米電視',"海爾冰箱","格力空調","AAA"] return render(request,"index.html",{"good_list":good_list}) 解釋: 一、首先,咱們從 django.shortcuts模塊導入了HttpResponse類,以及Python的datetime庫。 二、接着,咱們定義了current_datetime函數。它就是視圖函數。 每一個視圖函數都使用HttpRequest對象做爲第一個參數,而且一般稱之爲request。 注意,視圖函數的名稱並不重要;不須要用一個統一的命名方式來命名,以便讓Django識別它。 咱們將其命名爲current_datetime,是由於這個名稱可以精確地反映出它的功能。 三、這個視圖會返回一個HttpResponse對象,其中包含生成的響應。 每一個視圖函數都負責返回一個HttpResponse對象。 PythonCopy 二、HttpRequest對象 一、request屬性 django將請求報文中的請求行、首部信息、內容主體封裝成 HttpRequest 類中的屬性。 除了特殊說明的以外,其餘均爲只讀的。 request詳細解釋 1.HttpRequest.GET 一個相似於字典的對象,包含 HTTP GET 的全部參數。詳情請參考 QueryDict 對象。 2.HttpRequest.POST 一個相似於字典的對象,若是請求中包含表單數據,則將這些數據封裝成 QueryDict 對象。 POST 請求能夠帶有空的 POST 字典 —— 若是經過 HTTP POST 方法發送一個表單,可是表單中沒有任何的數據,QueryDict 對象依然會被建立。 所以,不該該使用 if request.POST 來檢查使用的是不是POST 方法;應該使用 if request.method == "POST" 另外:若是使用 POST 上傳文件的話,文件信息將包含在 FILES 屬性中。 注意:鍵值對的值是多個的時候,好比checkbox類型的input標籤,select標籤,須要用: request.POST.getlist("hobby") 3.HttpRequest.body 一個字符串,表明請求報文的主體。在處理非 HTTP 形式的報文時很是有用,例如:二進制圖片、XML,Json等。 可是,若是要處理表單數據的時候,推薦仍是使用 HttpRequest.POST 。 4.HttpRequest.path 一個字符串,表示請求的路徑組件(不含域名)。 例如:"/music/bands/the_beatles/" 5.HttpRequest.method 一個字符串,表示請求使用的HTTP 方法。必須使用大寫。 例如:"GET"、"POST" 6.HttpRequest.encoding 一個字符串,表示提交的數據的編碼方式(若是爲 None 則表示使用 DEFAULT_CHARSET 的設置,默認爲 'utf-8')。 這個屬性是可寫的,你能夠修改它來修改訪問表單數據使用的編碼。 接下來對屬性的任何訪問(例如從 GET 或 POST 中讀取數據)將使用新的 encoding 值。 若是你知道表單數據的編碼不是 DEFAULT_CHARSET ,則使用它。 7.HttpRequest.META 一個標準的Python 字典,包含全部的HTTP 首部。具體的頭部信息取決於客戶端和服務器,下面是一些示例: CONTENT_LENGTH —— 請求的正文的長度(是一個字符串)。 CONTENT_TYPE —— 請求的正文的MIME 類型。 HTTP_ACCEPT —— 響應可接收的Content-Type。 HTTP_ACCEPT_ENCODING —— 響應可接收的編碼。 HTTP_ACCEPT_LANGUAGE —— 響應可接收的語言。 HTTP_HOST —— 客服端發送的HTTP Host 頭部。 HTTP_REFERER —— Referring 頁面。 HTTP_USER_AGENT —— 客戶端的user-agent 字符串。 QUERY_STRING —— 單個字符串形式的查詢字符串(未解析過的形式)。 REMOTE_ADDR —— 客戶端的IP 地址。 REMOTE_HOST —— 客戶端的主機名。 REMOTE_USER —— 服務器認證後的用戶。 REQUEST_METHOD —— 一個字符串,例如"GET" 或"POST"。 SERVER_NAME —— 服務器的主機名。 SERVER_PORT —— 服務器的端口(是一個字符串)。 從上面能夠看到,除 CONTENT_LENGTH 和 CONTENT_TYPE 以外,請求中的任何 HTTP 首部轉換爲 META 的鍵時, 都會將全部字母大寫並將鏈接符替換爲下劃線最後加上 HTTP_ 前綴。 因此,一個叫作 X-Bender 的頭部將轉換成 META 中的 HTTP_X_BENDER 鍵。 8.HttpRequest.FILES 一個相似於字典的對象,包含全部的上傳文件信息。 FILES 中的每一個鍵爲
中的name,值則爲對應的數據。 注意,FILES 只有在請求的方法爲POST 且提交的