Django視圖層
阿新 • • 發佈：2018-07-12
coo 創建 short param lin code eight preview 信息
總結:
1. 視圖函數
- 視圖函數，簡稱視圖，是一個簡單的Python函數，它接受Web請求並且返回Web響應,本質就是一個函數
- 視圖的參數
- 一個HTTPResponse實例
- 通過正則表達式組獲取的位置參數
- 通過正則表達式組獲取的關鍵字參數
- 在應用目錄下默認有views.py文件, 一般視圖都定義在此文件中
- 如果處理功能過多,可將函數定義到不同的py文件中
- 視圖的對象
- HTTPResponse對象
- HTTPRequest對象
2. HTTPRequest對象
HTTP應用的信息是通過 請求報文 和 響應報文 傳遞的,其中 請求報文 由客戶端發送，其中包含和許多的信息，而 django 將這些信息封裝成了 HttpRequest 對象，該對象由 HttpRequest 類創建。每一個請求都會生成一個 HttpRequest 對象，django會將這個對象自動傳遞給響應的視圖函數，一般視圖函數約定俗成地使用 request 參數承接這個對象。
2.1 request屬性
- HTTPRequest.GET
- 一個類似於字典的對象，包含 HTTP GET 的所有參數。詳情請參考 QueryDict 對象
- 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")
- HTTPRequest.body
- 一個字符串，代表請求報文的主體。在處理非 HTTP 形式的報文時非常有用，例如：二進制圖片、XML,Json等。
- 如果要處理表單數據的時候，推薦還是使用 HttpRequest.POST 。
- HTTPRequest.path
- 一個字符串，表示請求的路徑組件（不含域名）。
- HTTPRequest.method
- 一個字符串，表示請求使用的HTTP 方法。必須使用大寫。
- HTTPRequest.encoding
- 一個字符串，表示提交的數據的編碼方式（如果為 None 則表示使用 DEFAULT_CHARSET 的設置，默認為 ‘utf-8‘）。
- 屬性是可寫的，你可以修改它來修改訪問表單數據使用的編碼。接下來對屬性的任何訪問（例如從 GET 或 POST 中讀取數據）將使用新的 encoding 值。
- 如果知道表單數據的編碼不是 DEFAULT_CHARSET ，則使用它。
- HTTPRequest.META
- 一個標準的Python 字典，包含所有的HTTP 首部。具體的頭部信息取決於客戶端和服務器
- HTTPRequest.FILES
- 一個類似於字典的對象，包含所有的上傳文件信息。
- FILES 中的每個鍵為
<input type="file" name="" />中的name，值則為對應的數據。 - FILES 只有在請求的方法為POST 且提交的
<form>帶有enctype="multipart/form-data" 的情況下才會包含數據。否則，FILES 將為一個空的類似於字典的對象。 - filename: 上傳文件名，用字符串表示
content_type: 上傳文件的Content Type
content: 上傳文件的原始內容
- HTTPRequest.COOKIES
- 一個標準的Python 字典，包含所有的cookie。鍵和值都為字符串。
- HTTPRequest.session
- 一個既可讀又可寫的類似於字典的對象，表示當前的會話。只有當Django 啟用會話的支持時才可用。
- HttpRequest.user(用戶認證組件下使用)
待整理 - HttpRequest.path_info
- 一個字符串，在某些 Web 服務器配置下，主機名後的 URL 部分被分成腳本前綴部分和路徑信息部分。path_info 屬性將始終包含路徑信息部分，不論使用的Web 服務器是什麽。使用它代替 path 可以讓代碼在測試和開發環境中更容易地切換。
- request.path 與 request.get_full_path()
- ‘‘‘
- 請求url:http://127.0.0.1:8000/index.html/23?a=1
- ‘‘‘
- request.path :
- request.path結果為:/index.html/23
- request.get_full_path()
- request.get_full_path()結果為:/index.html/23?a=1
2.2 request方法
- HttpRequest.get_full_path()
- 返回 path，如果可以將加上查詢字符串。例如："/music/bands/the_beatles/?print=true"
- HttpRequest.is_ajax()
- 如果請求是通過XMLHttpRequest 發起的，則返回True，方法是檢查 HTTP_X_REQUESTED_WITH 相應的首部是否是字符串‘XMLHttpRequest‘。
- 大部分現代的 JavaScript 庫都會發送這個頭部。如果你編寫自己的 XMLHttpRequest 調用（在瀏覽器端），你必須手工設置這個值來讓 is_ajax() 可以工作。
- 如果一個響應需要根據請求是否是通過AJAX 發起的，並且你正在使用某種形式的緩存例如Django 的 cache middleware，你應該使用 vary_on_headers(‘HTTP_X_REQUESTED_WITH‘) 裝飾你的視圖以讓響應能夠正確地緩存。
3. HTTPResponse對象
響應對象主要有三種形式:
- HTTPResponse()
- render()
- rendiret()
3.1 HTTPResponse()
HTTPResponse返回響應的字符串,對於HttpRequest請求對象來說，是由django自動創建的，但是，HttpResponse響應對象就必須我們自己創建。每個view請求處理方法必須返回一個HttpResponse響應對象。HttpResponse類在django.http.HttpResponse。render和redirect是在HTTPResponse對象上擴展的常用方法.
3.1 render()
將一個模板頁面中的模板語法進行渲染，最終渲染成一個html靜態文件作為響應體返回給瀏覽器
- render(request, template_name[, context]）
- ‘‘‘
- 結合一個給定的模板和一個給定的上下文字典，並返回一個渲染後的 HttpResponse 對象。
- ‘‘‘
參數:
- request： 用於生成響應的請求對象。
- template_name：要使用的模板的完整名稱，可選的參數
- context：添加到模板上下文的一個字典。默認是一個空字典。如果字典中的某個值是可調用的，視圖將在渲染模板之前調用它
- content_type：生成的文檔要使用的MIME類型。默認為DEFAULT_CONTENT_TYPE 設置的值。
- status：響應的狀態碼。默認為200。
3.2 redirect()
參數:
- 一個模型：將調用模型的get_absolute_url() 函數
- def my_view(request):
- ...
- object = MyModel.objects.get(...)
- return redirect(object)
- 一個視圖，可以帶有參數：將使用urlresolvers.reverse 來反向解析名稱
- def my_view(request):
- ...
- return redirect(‘some-view-name‘, foo=‘bar‘)
- 一個絕對的或相對的URL，將原封不動的作為重定向的位置。
- # 硬編碼URL
- def my_view(request):
- ...
- return redirect(‘/some/url/‘)
- # 完整URL
- def my_view(request):
- ...
- return redirect(‘http://example.com/‘)
- 默認返回一個臨時的重定向；傳遞permanent=True 可以返回一個永久的重定向。
- def my_view(request):
- ...
- object = MyModel.objects.get(...)
- return redirect(object, permanent=True)
3.3 render與redirect
render: 只是返回頁面內容，但是未發送第二次請求
redirect: 發送了第二次請求，url更新
總結:
- render返回一個登陸成功後的頁面，刷新該頁面將恢復到跳轉前頁面。而redirect則不會
- 如果頁面需要模板語言渲染,需要的將數據庫的數據加載到html,那麽render方法則不會顯示這一部分，render返回一個登陸成功頁面，不會經過url路由分發系統，也就是說，不會執行跳轉後url的視圖函數。這樣，返回的頁面渲染不成功；而redirect是跳轉到指定頁面，當登陸成功後，會在url路由系統進行匹配，如果有存在的映射函數，就會執行對應的映射函數。
3.4 301和302以及重定向
- 1. 301和302的區別
- - 共同點:
- 301和302狀態碼都表示重定向，就是說瀏覽器在拿到服務器返回的這個狀態碼後會自動跳轉到一個新的URL地址，這個地址可以從響應的Location首部中獲取(用戶看到的效果就是他輸入的地址A瞬間變成了另一個地址B)——這是它們的共同點。
- - 不同點:
- 1. 301表示舊地址A的資源已經被永久地移除了（這個資源不可訪問了），搜索引擎在抓取新內容的同時也將舊的網址交換為重定向之後的網址；
- 2. 302表示舊地址A的資源還在（仍然可以訪問），這個重定向只是臨時地從舊地址A跳轉到地址B，搜索引擎會抓取新的內容而保存舊的網址。SEO302好於301.
- 2. 重定向原因：
- 1. 網站調整（如改變網頁目錄結構）；
- 2. 網頁被移到一個新地址；
- 3. 網頁擴展名改變(如應用需要把.php改成.Html或.shtml)。
- - 這種情況下，如果不做重定向，則用戶收藏夾或搜索引擎數據庫中舊地址只能讓訪問客戶得到一個404頁面錯誤信息，訪問流量白白喪失；
- - 再者某些註冊了多個域名的網站，也需要通過重定向讓訪問這些域名的用戶自動跳轉到主站點等。
Django視圖層