Django的視圖層
阿新 • • 發佈：2018-10-24
clas som 技術 %s 認證 自己的 請求 .com cat
一.視圖函數
一個視圖函數，簡稱視圖，是一個簡單的Python 函數，它接受Web請求並且返回Web響應。響應可以是一張網頁的HTML內容，一個重定向，一個404錯誤，一個XML文檔，或者一張圖片. . . 是任何東西都可以。無論視圖本身包含什麽邏輯，都要返回響應。代碼寫在哪裏也無所謂，只要它在你的Python目錄下面。除此之外沒有更多的要求了——可以說“沒有什麽神奇的地方”。為了將代碼放在某處，約定是將視圖放置在項目或應用程序目錄中的名為views.py的文件中
下面是一個返回當前日期和時間作為HTML文檔的視圖：
from django.shortcuts importrender, HttpResponse, HttpResponseRedirect, redirect import datetime def current_datetime(request): now = datetime.datetime.now() html = "<html><body>It is now %s.</body></html>" % now return HttpResponse(html)
讓我們逐行閱讀上面的代碼：
- 首先,我們從diango.shortcuts模塊導入了HTTPResponse類,以及Python的datetime庫
- 接著,我們定義了current_datetime函數,它就是視圖函數,每個視圖函數都使用HTTPRequest對象作為第一個參數,並且通常稱之為request; PS:註意,視圖函數的名稱並不重要;不需要用一個統一的命名方式來命名,以便讓Django識別它,我們將其命名為current_datetime,是因為這個名稱能夠精確的反應出它的功能
- 這個視圖會返回一個HTTPResponse對象,其中包含生成的響應,每個視圖函數都負責返回一個HTTPResponse對象
視圖層，熟練掌握兩個對象即可：請求對象(request)和響應對象(HttpResponse)
二.HttpRequest對象
1.request屬性
django將請求報文中的請求行、首部信息、內容主體封裝成 HttpRequest 類中的屬性。 除了特殊說明的之外，其他均為只讀的。
/* 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 中的每個鍵為<input type="file" name="" /> 中的name，值則為對應的數據。 註意，FILES 只有在請求的方法為POST 且提交的<form> 帶有enctype="multipart/form-data" 的情況下才會 包含數據。否則，FILES 將為一個空的類似於字典的對象。 9.HttpRequest.COOKIES 一個標準的Python 字典，包含所有的cookie。鍵和值都為字符串。 10.HttpRequest.session 一個既可讀又可寫的類似於字典的對象，表示當前的會話。只有當Django 啟用會話的支持時才可用。 完整的細節參見會話的文檔。 11.HttpRequest.user(用戶認證組件下使用) 一個 AUTH_USER_MODEL 類型的對象，表示當前登錄的用戶。 如果用戶當前沒有登錄，user 將設置為 django.contrib.auth.models.AnonymousUser 的一個實例。你可以通過 is_authenticated() 區分它們。 例如： if request.user.is_authenticated(): # Do something for logged-in users. else: # Do something for anonymous users. user 只有當Django 啟用 AuthenticationMiddleware 中間件時才可用。 ------------------------------------------------------------------------------------- 匿名用戶 class models.AnonymousUser django.contrib.auth.models.AnonymousUser 類實現了django.contrib.auth.models.User 接口，但具有下面幾個不同點： id 永遠為None。 username 永遠為空字符串。 get_username() 永遠返回空字符串。 is_staff 和 is_superuser 永遠為False。 is_active 永遠為 False。 groups 和 user_permissions 永遠為空。 is_anonymous() 返回True 而不是False。 is_authenticated() 返回False 而不是True。 set_password()、check_password()、save() 和delete() 引發 NotImplementedError。 New in Django 1.8: 新增 AnonymousUser.get_username() 以更好地模擬 django.contrib.auth.models.User。 */
2.request常用方法
/* 1.HttpRequest.get_full_path() 返回 path，如果可以將加上查詢字符串。 例如："/music/bands/the_beatles/?print=true" 2.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‘) 裝飾你的視圖以讓響應能夠正確地緩存。 */
三.HTTPResponse對象
1.響應對象主要有三種形式:
- HttpResponse()
- render
- redirect()
HttpResponse()括號內直接跟一個具體的字符串作為響應體，比較直接很簡單，所以這裏主要介紹後面兩種形式。
2.render()
render(request, template_name[, context]） #結合一個給定的模板和一個給定的上下文字典，並返回一個渲染後的HttpResponse 對象。
(1).參數:
request:用於生成響應的請求對象
template_name:要使用的模板的完整名稱,可選的參數
context:添加到模板上下文的一個字典,默認是一個空字典,如果字典中的某個值是可調用的,視圖將在渲染模板之前調用他
render方法就是將一個模板頁面中的模板語法進行渲染,最終渲染成一個html頁面作為響應體
3.redirect() 重定向
傳遞要重定向的一個硬編碼的URL
def my_view(request): ... return redirect(‘/some/url/‘)
也可以是一個完整的URL：
def my_view(request): ... return redirect(‘http://example.com/‘)
key：兩次請求
1.301和302的區別。 301和302狀態碼都表示重定向，就是說瀏覽器在拿到服務器返回的這個狀態碼後會自動跳轉到一個新的URL地址，這個地址可以從響應的Location首部中獲取 （用戶看到的效果就是他輸入的地址A瞬間變成了另一個地址B）——這是它們的共同點。 他們的不同在於。301表示舊地址A的資源已經被永久地移除了（這個資源不可訪問了），搜索引擎在抓取新內容的同時也將舊的網址交換為重定向之後的網址； 302表示舊地址A的資源還在（仍然可以訪問），這個重定向只是臨時地從舊地址A跳轉到地址B，搜索引擎會抓取新的內容而保存舊的網址。 SEO302好於301 2.重定向原因： （1）網站調整（如改變網頁目錄結構）； （2）網頁被移到一個新地址； （3）網頁擴展名改變(如應用需要把.php改成.Html或.shtml)。 這種情況下，如果不做重定向，則用戶收藏夾或搜索引擎數據庫中舊地址只能讓訪問客戶得到一個404頁面錯誤信息，訪問流量白白喪失；再者某些註冊了多個域名的 網站，也需要通過重定向讓訪問這些域名的用戶自動跳轉到主站點等。 關於301與302View Code
用redirect可以解釋APPEND_SLASH的用法！
Django的視圖層