一個視圖函數簡稱稱視圖，是一個簡單的Python 函數，它接受Web請求并且傳回Web響應。響應可以是一張網頁的HTML内容，一個重定向，一個404錯誤，一個XML文檔，或者一張圖檔. . . 是任何東西都可以。無論視圖本身包含什麼邏輯，都要傳回響應。代碼寫在哪裡也無所謂，隻要它在你的Python目錄下面。除此之外沒有更多的要求了——可以說“沒有什麼神奇的地方”。為了将代碼放在某處，約定是将視圖放置在項目或應用程式目錄中的名為views.py的檔案中。
下面是一個傳回目前日期和時間作為HTML文檔的視圖：
from django.shortcuts import render, 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) 讓我們逐行閱讀上面的代碼：
- 首先，我們從 django.shortcuts子產品導入了HttpResponse類，以及Python的datetime庫。
-
接着，我們定義了current_datetime函數。它就是視圖函數。每個視圖函數都使用HttpRequest對象作為第一個參數，并且通常稱之為request。
注意,視圖函數的名稱并不重要；不需要用一個統一的命名方式來命名，以便讓Django識别它。我們将其命名為current_datetime，是因為這個名稱能夠精确地反映出它的功能。
- 這個視圖會傳回一個HttpResponse對象，其中包含生成的響應。每個視圖函數都負責傳回一個HttpResponse對象。
Django之路——4 Django的視圖層
視圖層，熟練掌握兩個對象即可：請求對象(request)和響應對象(HttpResponse)
HttpRequest對象
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。
*/ 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對象
響應對象主要有三種形式：
- HttpResponse()
- render()
- redirect()
HttpResponse()括号内直接跟一個具體的字元串作為響應體，比較直接很簡單，是以這裡主要介紹後面兩種形式。
|
參數：
request： 用于生成響應的請求對象。
template_name：要使用的模闆的完整名稱，可選的參數
context：添加到模闆上下文的一個字典。預設是一個空字典。如果字典中的某個值是可調用的，視圖将在渲染模闆之前調用它。
render方法就是将一個模闆頁面中的模闆文法進行渲染，最終渲染成一個html頁面作為響應體。 傳遞要重定向的一個寫死的URL
|
也可以是一個完整的URL：
|
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頁面錯誤資訊，通路流量白白喪失；再者某些注冊了多個域名的
網站，也需要通過重定向讓通路這些域名的使用者自動跳轉到主站點等。 用redirect可以解釋APPEND_SLASH的用法！