視圖層是 Django 處理請求的核心代碼層,咱們大多數 Python 代碼都集中在這一層面。它對外接收用戶請求,對內調度模型層和模版層,統合數據庫和前端,最後根據業務邏輯,將處理好的數據,與前端結合,返回給用戶。視圖層是真正的後端,是 Python工程師的‘主營業務’。Django 的視圖層包含下面一些主要內容:html
1.URL 路由前端
2.視圖函數web
3.快捷方式ajax
4.請求與響應正則表達式
URL 是 Web 服務的入口,用戶經過瀏覽器發送過來的任何請求,都是發送到一個指定的 URL 地址,而後被響應。數據庫
在 Django 項目中編寫路由,就是向外暴露咱們接收哪些 URL 的請求,除此以外的任何 URL 都不被處理,也沒有返回。通俗地理解,不恰當的形容,URL 路由是你的 Web服務對外暴露的 API。django
URL 路由在 Django 項目中的體現就是 urls.py 文件,這個文件能夠有不少個。實際上Django 提倡項目有個根 urls.py,各 app 下分別有本身的一個 urls.py,既集中又分治,是一種解耦的模式。後端
隨便新建一個 Django 項目,默認會自動爲咱們建立一個/project_name/urls.py 文件,而且自動包含下面的內容,這就是項目的根 URL:瀏覽器
前面一堆幫助性的文字,咱們不用管,關鍵是默認導入了 url 和 admin,而後有一條指向 admin 後臺的 url 路徑。安全
咱們本身要編寫的 url 路由,基本也是這個套路。
一、Django 如何處理請求
當用戶請求一個頁面時,Django 根據下面的邏輯執行操做:
(1)決定要使用的根 URLconf 模塊。一般,這是 ROOT_URLCONF 設置的值,你能夠自定義項目入口 url 是哪一個文件。
(2) 加載該模塊並尋找可用的 urlpatterns。 它是 django.conf.urls.url()實例的一個列表。
(3) 依次匹配每一個 URL 模式,在與請求的 URL 相匹配的第一個模式停下來。也就是說,url 匹配是從上往下的短路操做,因此 url 在列表中的位置很是關鍵。
(4)導入並調用匹配行中給定的視圖,該視圖是一個簡單的 Python 函數(被稱爲視圖函數),或基於類的視圖。 視圖將得到以下參數:
(01) 一個 HttpRequest 實例。
(02) 若是匹配的正則表達式返回了沒有命名的組,那麼正則表達式匹配的內容將做爲位置參數提供給視圖。
(03) 關鍵字參數由正則表達式匹配的命名組組成,可是能夠被django.conf.urls.url()的可選參數 kwargs 覆蓋。
(5)若是沒有匹配到正則表達式,或者過程當中拋出異常,將調用一個適當的錯誤處理視圖。
簡單示例
下面是一個簡單的 URLconf:
from django.conf.urls import url from booktest import views urlpatterns = [ url(r'^articles/2003/$', views.special_case_2003), url(r'^articles/([0-9]{4})/$', views.year_archive), url(r'^articles/([0-9]{4})/([0-9]{2})/$', views.month_archive), url(r'^articles/([0-9]{4})/([0-9]{2})/([0-9]+)/$', views.article_detail), ]
咱們要編寫的就是上面 urlpatterns 列表中的一條條 url,每條 url,都是 urlpatterns 列表的一個元素。前後順序有重要關係,不能隨意擺放。最後一條的末尾建議
添加一個逗號。
urlpatterns 中的每條正則表達式在第一次訪問時被自動編譯,所以其匹配速度是很是快的。
注意:
1.若要從 URL 中捕獲一個值,只須要在它周圍放置一對圓括號。
2. 不須要添加前導的反斜槓,由於每一個 URL 都有。 例如,應該是^articles 而不是^/articles。
3. 每一個正則表達式前面的'r'是可選的可是建議加上。它告訴 Python 這個字符串是「原始的」 —— 字符串中任何字符都不該該轉義。
根據上面的 urlconf,下面是一些請求的例子,以及它們將匹配到的 url:
1. /articles/2005/03/將匹配列表中的第三個模式。Django 將調用函數views.month_archive(request, '2005', '03')。
2. /articles/2005/3/不匹配任何 URL 模式,由於列表中的第三個模式要求月份是兩個數字。
3./articles/2003/將匹配列表中的第一個模式不是第二個,由於模式按順序從上往下匹配,第一個會首先被匹配。Django 會調用函數views.special_case_2003(request)
4. /articles/2003 不匹配任何一個模式,由於每一個模式都要求 URL 以一個斜槓結尾。
5. /articles/2003/03/03/將匹配最後一個模式。Django 將調用函數views.article_detail(request, '2003', '03', '03')。
不少時候,咱們須要獲取 URL 中的一些片斷,做爲參數,傳遞給處理請求的視圖。
上面的示例使用簡單的、沒有命名的正則表達式組(經過圓括號)來捕獲 URL 中的值並以位置參數的形式傳遞給視圖。
可使用命名的正則表達式組來捕獲 URL 中的值並以關鍵字參數傳遞給視圖。
在 Python 的正則表達式中,命名組的語法是(?P<name>pattern),其中 name 是組的名稱,pattern 是要匹配的模式。
下面是以上 URLconf 使用命名組的重寫:
from django.conf.urls import url from . import views urlpatterns = [ url(r'^articles/2003/$', views.special_case_2003), url(r'^articles/(?P<year>[0-9]{4})/$', views.year_archive), url(r'^articles/(?P<year>[0-9]{4})/(?P<month>[0-9]{2})/$',views.month_archive), url(r'^articles/(?P<year>[0-9]{4})/(?P<month>[0-9]{2})/(?P<day>[0-9]{2})/$', views.article_detail), ]
這個實現與前面的示例徹底相同,只有一個細微的差異:捕獲的值做爲關鍵字參數而不是位置參數傳遞給視圖函數。 像這樣:
1. /articles/2005/03/請求將調用 views.month_archive(request, year='2005',month='03')函數,而不是 views.month_archive(request, '2005', '03')。
2. /articles/2003/03/03/請求將調用函數 views.article_detail(request,year='2003', month='03', day='03')。
在實際應用中,這讓你的 URLconf 更加明晰且不容易產生參數順序問題的錯誤。針對命名組和非命名組:
1.若是有命名參數,則使用這些命名參數,忽略非命名參數。
2.不然,它將以位置參數傳遞全部的非命名參數。
請求的 URL 被看作是一個普通的 Python 字符串,URLconf 在其上查找並匹配。進行匹配時將不包括 GET 或 POST 請求方式的參數以及域名。
例如,在 https://www.example.com/myapp/的請求中,URLconf 將查找 myapp/。
在 https://www.example.com/myapp/?page=3 的請求中,URLconf 也將查找 myapp/。
URLconf 不檢查使用何種 HTTP 請求方法,全部請求方法 POST、GET、HEAD 等都將路由到同一個 URL 的同一個視圖。在視圖中,才根據具體請求方法的不一樣,進行不一樣的處理。
每一個捕獲的參數都做爲一個普通的 Python 字符串傳遞給視圖,即使被捕獲的‘100’看起來像個整數,但其實是個字符串‘100’。 例如,下面這行 URLconf 中:
url(r'^articles/(?P<year>[0-9]{4})/$', views.year_archive),
傳遞給 views.year_archive()的 year 參數將是一個字符串,不是整數,即便[0-9]{4}只匹配整數字符串。
有一個小技巧,咱們能夠指定視圖參數的默認值。 下面是一個 URLconf 和視圖的示例:
# URLconf from django.conf.urls import url from . import views urlpatterns = [ url(r'^blog/$', views.page), url(r'^blog/page(?P<num>[0-9]+)/$', views.page), ] # View (in blog/views.py) def page(request, num="1"): # Output the appropriate page of blog entries, according to num. ...
在上面的例子中,兩個 URL 模式指向同一個視圖 views.page。可是第一個模式不會從URL 中捕獲任何值。 若是第一個模式匹配,page()函數將使用 num 參數的默認值"1"。若是第二個模式匹配,page()將使用捕獲的 num 值。
2、路由轉發
一般,咱們會在每一個 app 裏,各自建立一個 urls.py 路由模塊,而後從根路由出發,將app 所屬的 url 請求,所有轉發到相應的 urls.py 模塊中。
例如,下面是 Django 網站自己的 URLconf 節選。 它包含許多其它 URLconf:
from django.conf.urls import include, url urlpatterns = [ url(r'^community/', include('django_website.aggregator.urls')), url(r'^contact/', include('django_website.contact.urls')), ]
路由轉發使用的是 include()方法,須要提早導入,它的參數是轉發目的地路徑的字符串,路徑以圓點分割。
注意,這個例子中的正則表達式沒有包含$(字符串結束匹配符),可是包含一個末尾的斜槓。 每當 Django 遇到 include()時,它會去掉 URL 中匹配的部分並將剩下的字符串發送給 include 的 URLconf 作進一步處理,也就是轉發到二級路由去。
看下面的 URLconf:
from django.conf.urls import url from . import views urlpatterns = [ url(r'^(?P<page_slug>[\w-]+)-(?P<page_id>\w+)/history/$', views.history), url(r'^(?P<page_slug>[\w-]+)-(?P<page_id>\w+)/edit/$', views.edit), url(r'^(?P<page_slug>[\w-]+)-(?P<page_id>\w+)/discuss/$', views.discuss), url(r'^(?P<page_slug>[\w-]+)-(?P<page_id>\w+)/permissions/$',views.permissions), ]
上面的路由寫得很差,咱們能夠改進它,只須要聲明共同的路徑前綴一次,並將後面的部分分組轉發:
from django.conf.urls import include, url from . import views urlpatterns = [ url(r'^(?P<page_slug>[\w-]+)-(?P<page_id>\w+)/', include([ url(r'^history/$', views.history), url(r'^edit/$', views.edit), url(r'^discuss/$', views.discuss), url(r'^permissions/$', views.permissions), ])), ]
這樣就優雅多了,也清爽多了。
被轉發的 URLconf 會收到來自父 URLconf 捕獲的全部參數,看下面的例子:
# In settings/urls/main.py from django.conf.urls import include, url urlpatterns = [ url(r'^(?P<username>\w+)/blog/', include('foo.urls.blog')), ] # In foo/urls/blog.py from django.conf.urls import url from . import views urlpatterns = [ url(r'^$', views.blog.index), url(r'^archive/$', views.blog.archive), ]
在上面的例子中,捕獲的"username"變量將被傳遞給 include()指向的 URLconf,再進一步傳遞給對應的視圖。
URLconfs 具備一個鉤子(hook),容許你傳遞一個 Python 字典做爲額外的關鍵字參數給視圖函數。
像這樣:
from django.conf.urls import url from . import views urlpatterns = [ url(r'^blog/(?P<year>[0-9]{4})/$', views.year_archive, {'foo': 'bar'}), ]
在上面的例子中,對於/blog/2005/請求,Django 將調用 views.year_archive(request,year='2005', foo='bar')。理論上,你能夠在這個字典裏傳遞任何你想要的傳遞的東西。可是要注意,URL 模式捕獲的命名關鍵字參數和在字典中傳遞的額外參數有可能具備
相同的名稱,這會發生衝突,要避免。
相似上面,也能夠傳遞額外的參數給 include()。參數會傳遞給 include 指向的 urlconf中的每一行。
例如,下面兩種 URLconf 配置方式在功能上徹底相同:
配置一:
# main.py from django.conf.urls import include, url urlpatterns = [ url(r'^blog/', include('inner'), {'blogid': 3}), ] # inner.py from django.conf.urls import url from mysite import views urlpatterns = [ url(r'^archive/$', views.archive), url(r'^about/$', views.about), ]
配置二:
# main.py from django.conf.urls import include, url from mysite import views urlpatterns = [ url(r'^blog/', include('inner')), ] # inner.py from django.conf.urls import url urlpatterns = [ url(r'^archive/$', views.archive, {'blogid': 3}), url(r'^about/$', views.about, {'blogid': 3}), ]
注意,只有當你肯定被 include 的 URLconf 中的每一個視圖都接收你傳遞給它們的額外的參數時纔有意義,不然其中一個以上視圖不接收該參數都將致使錯誤異常。
若是在視圖、模板中使用硬編碼的連接,在 urlconf 發生改變時,維護是一件很是麻煩的事情。咱們須要一種安全、可靠、自適應的機制,當修改 URLconf 中的代碼後,無需在項目源碼中大範圍搜索、替換失效的硬編碼 URL。爲了解決這個問題,Django 提供了一
種解決方案,只需在 URL 中提供一個 name 參數,並賦值一個你自定義的、好記的、直觀的字符串。經過這個 name 參數,能夠反向解析 URL、反向 URL 匹配、反向 URL 查詢或者簡單的URL 反查。
在須要解析 URL 的地方,對於不一樣層級,Django 提供了不一樣的工具用於 URL 反查:
1.在模板語言中:使用 url 模板標籤。(也就是寫前端網頁時)
2.在 Python 代碼中:使用 reverse()函數。(也就是寫視圖函數等狀況時)
3.在更高層的與處理 Django 模型實例相關的代碼中:使用 get_absolute_url()方法。(也就是在模型 model 中)
範例:
考慮下面的 URLconf:
from django.conf.urls import url from . import views urlpatterns = [ url(r'^articles/([0-9]{4})/$', views.year_archive, name='news-year-archive'), ]
某一年 nnnn 對應的歸檔的 URL 是/articles/nnnn/。
能夠在模板的代碼中使用下面的方法得到它們:
<a href="{% url 'news-year-archive' 2012 %}">2012 Archive</a> # 注意模版語言的用法,注意參數的傳遞方法
在 Python 代碼中,這樣使用:
from django.urls import reverse from django.http import HttpResponseRedirect def redirect_to_year(request): year = 2006 # ...注意參數的傳遞方法 return HttpResponseRedirect(reverse('news-year-archive', args=(year,)))
其中,起到核心做用的是咱們經過 name='news-year-archive'爲那條 url 起了一個能夠被引用的名稱。
URL 命名空間
URL 命名空間能夠保證反查到惟一的 URL,即便不一樣的 app 使用相同的 URL 名稱。
第三方應用始終使用帶命名空間的 URL 是一個很好的作法。
include()中設置 namespace 參數
url()中設置 name 參數
能夠以 namespace:name 來訪問 url。
視圖函數,簡稱視圖,本質上是一個簡單的 Python 函數,它接受 Web 請求而且返回Web 響應。
響應的內容能夠是 HTML 網頁、重定向、404 錯誤,XML 文檔或圖像等任何東西。但是,不管視圖自己是個什麼處理邏輯,最好都返回某種響應。
視圖函數的代碼寫在哪裏也無所謂,只要它在你的 Python 目錄下面。可是一般咱們約定將視圖放置在項目或應用程序目錄中的名爲 views.py 的文件中。
下面是一個返回當前日期和時間做爲 HTML 文檔的視圖:
from django.http import HttpResponse import datetime def current_datetime(request): now = datetime.datetime.now() html = "<html><body>It is now %s.</body></html>" % now return HttpResponse(html)
讓咱們逐行分析一下上面的代碼:
1.首先,從 django.http 模塊導入了 HttpResponse 類,以及 Python 的 datetime庫。
2.接着,咱們定義了 current_datetime 視圖函數。
3.每一個視圖函數都接收一個 HttpRequest 對象做爲第一位置參數,通常取名爲request,你能夠取別的名字,但這不符合潛規則,最好不要那麼作。
4. 視圖函數的名稱沒有強制規則,但儘可能不要和 Python 及 Django 內置的各類名稱重名,而且儘可能精確地反映出它的功能,好比這裏的 current_datetime。該視圖返回一個 HttpResponse 對象,其中包含生成的 HTML 頁面。
在 Django 中返回 HTTP 錯誤代碼是很是簡單的。
HttpResponse 的許多子類對應着除了 200(表明「OK」)之外的一些經常使用的 HTTP 狀態碼。
爲了標示一個錯誤,能夠直接返回那些子類中的一個實例,而不是普通的HttpResponse。像下面這樣:
from django.http import HttpResponse, HttpResponseNotFound def my_view(request): if foo: return HttpResponseNotFound('<h1>Page not found</h1>') else: return HttpResponse('<h1>Page was found</h1>')
Django 爲 404 錯誤提供了一個特化的子類 HttpResponseNotFound。因爲一些狀態碼不太經常使用,因此不是每一個狀態碼都有一個特化的子類。
也能夠向 HttpResponse 的構造器傳遞 HTTP 狀態碼,來建立你想要的任何狀態碼的返回類。 像下面這樣:
from django.http import HttpResponse def my_view(request): # Return a "created" (201) response code. return HttpResponse(status=201)
關鍵是在返回中提供 status=201 參數。別的什麼 303 之類的錯誤均可以參照上面的例子。
class django.http.Http404
這是一個 Django 內置的異常類。能夠在須要的地方認爲彈出它,Django 會捕獲它,而且帶上 HTTP404 錯誤碼返回你當前 app 的標準錯誤頁面或者自定義錯誤頁面。像下面這樣:
from django.http import Http404 from django.shortcuts import render from polls.models import Poll def detail(request, poll_id): try: p = Poll.objects.get(pk=poll_id) except Poll.DoesNotExist: raise Http404("Poll does not exist") return render(request, 'polls/detail.html', {'poll': p})
Django 在 django.shortcuts 模塊中,爲咱們提供了不少快捷方便的類和方法,它們都很重要,使用頻率很高。
render()
render(request, template_name, context=None, content_type=None, status=None,using=None)[source]
結合一個給定的模板和一個給定的上下文字典,返回一個渲染後的 HttpResponse 對象。
必需參數:
1.request:視圖函數處理的當前請求,封裝了請求頭的全部數據,其實就是視圖參數 request。
2. template_name:要使用的模板的完整名稱或者模板名稱的列表。若是是一個列表,將使用其中可以查找到的第一個模板。
可選參數:
1.context:添加到模板上下文的一個數據字典。默認是一個空字典。能夠將認可須要提供給模板的數據以字典的格式添加進去。
2.content_type:用於生成的文檔的 MIME 類型。 默認爲DEFAULT_CONTENT_TYPE 設置的值。
3.status:響應的狀態代碼。 默認爲 200。
4.using:用於加載模板使用的模板引擎的 NAME。
範例:
下面的例子將渲染模板 myapp/index.html,MIME 類型爲 application/xhtml+xml:
from django.shortcuts import render def my_view(request): # View code here... return render(request, 'myapp/index.html', {'foo': 'bar',}, content_type='application/xhtml+xml')
這個示例等同於:
from django.http import HttpResponse from django.template import loader def my_view(request): # View code here... t = loader.get_template('myapp/index.html') c = {'foo': 'bar'} return HttpResponse(t.render(c, request),content_type='application/xhtml+xml')
redirect()
redirect(to, permanent=False, args, *kwargs)[source]
根據傳遞進來的 url 參數,返回 HttpResponseRedirect。
參數 to 能夠是:
1.一個模型:將調用模型的 get_absolute_url()函數,反向解析出目的 url;
2. url 名稱:可能帶有參數,reverse()將用於反向解析 url;
3.一個絕對的或相對的 URL:將原封不動的做爲重定向的目標位置。默認狀況下是臨時重定向,若是設置 permanent=True 將永久重定向。
範例:
調用對象的 get_absolute_url()方法來重定向 URL:
from django.shortcuts import redirect def my_view(request): object = MyModel.objects.get(...) return redirect(object)
使用 reverse()方法反向解析 url:
def my_view(request): ... return redirect(reverse('some-view-name', foo='bar'))
重定向到硬編碼的 URL:
def my_view(request): ... return redirect('/some/url/')
重定向到一個完整的 URL:
def my_view(request): ... return redirect('https://example.com/')
全部上述形式都接受 permanent 參數;若是設置爲 True,將返回永久重定向:
def my_view(request): ... object = MyModel.objects.get(...) return redirect(object, permanent=True)
get_object_or_404()
get_object_or_404(klass, args, *kwargs)[source]
這個方法,很是有用,請必定熟記。經常使用於查詢某個對象,找到了則進行下一步處理,若是未找到則給用戶返回 404 頁面。
在後臺,Django 實際上是調用了模型管理器的 get()方法,只會返回一個對象。不一樣的是,若是 get()發生異常,會引起 Http404 異常,從而返回 404 頁面,而不是模型的DoesNotExist 異常。
必需參數:
1.klass:要獲取的對象的 Model 類名或者 Queryset 等;
2.**kwargs:查詢的參數,格式應該能夠被 get()接受。
範例:
從 MyModel 中使用主鍵 1 來獲取對象:
from django.shortcuts import get_object_or_404 def my_view(request): my_object = get_object_or_404(MyModel, pk=1)
除了傳遞 Model 名稱,還能夠傳遞一個 QuerySet 實例:
get_object_or_404(Book, title__startswith='M', pk=1)
get_list_or_404()
get_list_or_404(klass, args, *kwargs)[source]
這其實就是 get_object_or_404 多值獲取版本。
在後臺,返回一個給定模型管理器上 filter()的結果,並將結果映射爲一個列表,若是結果爲空則彈出 Http404 異常。
必需參數:
1.klass:獲取該列表的一個 Model、Manager 或 QuerySet 實例。
2.**kwargs:查詢的參數,格式應該能夠被 filter()接受。
範例:
下面的示例從 MyModel 中獲取全部發布出來的對象:
from django.shortcuts import get_list_or_404 def my_view(request): my_objects = get_list_or_404(MyModel, published=True)
每當一個用戶請求發送過來,Django 將 HTTP 數據包中的相關內容,打包成爲一個HttpRequest 對象,並傳遞給每一個視圖函數做爲第一位置參數,也就是 request,供我們調用。
HttpRequest 對象中包含了很是多的重要的信息和數據,應該熟練掌握它。
HttpRequest 對象的大部分屬性是隻讀的,除非特別註明。
HttpRequest.scheme
字符串類型,表示請求的協議種類,'http'或'https'。
HttpRequest.body
bytes 類型,表示原始 HTTP 請求的正文。它對於處理非 HTML 形式的數據很是有用:二進制圖像、XML 等。若是要處理常規的表單數據,應該使用 HttpRequest.POST。還可使用相似讀寫文件的方式從 HttpRequest 中讀取數據,參見 HttpRequest.read()。
HttpRequest.path
字符串類型,表示當前請求頁面的完整路徑,可是不包括協議名和域名。例如:"/music/bands/the_beatles/"。這個屬性,常被用於咱們進行某項操做時,若是不經過,返回用戶先前瀏覽的頁面。很是有用!
HttpRequest.path_info
在某些 Web 服務器配置下,主機名後的 URL 部分被分紅腳本前綴部分和路徑信息部分。path_info 屬性將始終包含路徑信息部分,不論使用的 Web 服務器是什麼。使用它代替 path 可讓代碼在測試和開發環境中更容易地切換。
HttpRequest.method
字符串類型,表示請求使用的 HTTP 方法。默認爲大寫。 像這樣:
if request.method == 'GET': do_something() elif request.method == 'POST': do_something_else()
經過這個屬性來判斷請求的方法,而後根據請求的方法不一樣,在視圖中執行不一樣的代碼。
HttpRequest.encoding
字符串類型,表示提交的數據的編碼方式(若是爲 None 則表示使用DEFAULT_CHARSET 設置)。 這個屬性是可寫的,能夠經過修改它來改變表單數據的編碼。任何隨後的屬性訪問(例如 GET 或 POST)將使用新的編碼方式。
HttpRequest.content_type
表示從 CONTENT_TYPE 頭解析的請求的 MIME 類型。
HttpRequest.content_params
包含在 CONTENT_TYPE 標題中的鍵/值參數字典。
HttpRequest.GET
一個相似於字典的對象,包含 GET 請求中的全部參數。 詳情參考 QueryDict。
HttpRequest.POST
一個包含全部 POST 請求的參數,以及包含表單數據的字典。 詳情請參考 QueryDict。若是須要訪問請求中的原始或非表單數據,可使用 HttpRequest.body 屬性。
注意:請使用 if request.method == "POST"來判斷一個請求是否 POST 類型,而不要使用 if request.POST。
POST 中不包含上傳文件的數據。
HttpRequest.COOKIES
包含全部 Cookie 信息的字典。 鍵和值都爲字符串。能夠相似字典類型的方式,在cookie 中讀寫數據,可是注意 cookie 是不安全的,所以,不要寫敏感重要的信息。
HttpRequest.FILES
一個相似於字典的對象,包含全部上傳的文件數據。 FILES 中的每一個鍵爲<input type="file" name="" />中的 name 屬性值。 FILES 中的每一個值是一個 UploadedFile。要在 Django 中實現文件上傳,就要靠這個屬性!
HttpRequest.META
包含全部 HTTP 頭部信息的字典。 可用的頭部信息取決於客戶端和服務器,下面是一些示例:
CONTENT_LENGTH —— 請求正文的長度(以字符串計)。
CONTENT_TYPE —— 請求正文的 MIME 類型。
HTTP_ACCEPT —— 可接收的響應 Content-Type。
HTTP_ACCEPT_ENCODING —— 可接收的響應編碼類型。
HTTP_ACCEPT_LANGUAGE —— 可接收的響應語言種類。
HTTP_HOST —— 客服端發送的 Host 頭部。
HTTP_REFERER —— Referring 頁面。
HTTP_USER_AGENT —— 客戶端的 user-agent 字符串。
QUERY_STRING —— 查詢字符串。
REMOTE_ADDR —— 客戶端的 IP 地址。想要獲取客戶端的 ip 信息,就在這裏!
REMOTE_HOST —— 客戶端的主機名。
REMOTE_USER —— 服務器認證後的用戶,若是可用。
REQUEST_METHOD —— 表示請求方法的字符串,例如"GET" 或"POST"。
SERVER_NAME —— 服務器的主機名。
SERVER_PORT —— 服務器的端口(字符串)。
以上只是比較重要和經常使用的,還有不少未列出。
HttpRequest.resolver_match
表明一個已解析的 URL 的 ResolverMatch 實例。Django 不會自動設置下面這些屬性,而是由你本身在應用程序中設置並使用它們。
HttpRequest.current_app
表示當前 app 的名字。url 模板標籤將使用其值做爲 reverse()方法的 current_app 參數。
HttpRequest.urlconf
設置當前請求的根 URLconf,用於指定不一樣的 url 路由進入口,這將覆蓋 settings 中的ROOT_URLCONF 設置。將它的值修改成 None,能夠恢復使用 ROOT_URLCONF 設置。
Django 的 contrib 應用中包含的一些中間件會在請求上設置屬性。
HttpRequest.session
SessionMiddleware 中間件:一個可讀寫的,相似字典的對象,表示當前會話。咱們要保存用戶狀態,回話過程等等,靠的就是這個中間件和這個屬性。
HttpRequest.site
CurrentSiteMiddleware 中間件:get_current_site()方法返回的 Site 或 RequestSite 的實例,表明當前站點是哪一個。
Django 是支持多站點的,若是你同時上線了幾個站點,就須要爲每一個站點設置一個站點 id。
HttpRequest.user
AuthenticationMiddleware 中間件:表示當前登陸的用戶的 AUTH_USER_MODEL 的實例,這個模型是 Django 內置的 Auth 模塊下的 User 模型。若是用戶當前未登陸,則user 將被設置爲 AnonymousUser 的實例。
HttpRequest.get_host()[source]
根據 HTTP_X_FORWARDED_HOST 和 HTTP_HOST 頭部信息獲取請求的原始主機。 如果這兩個頭部沒有提供相應的值,則使用 SERVER_NAME 和 SERVER_PORT。
例如:"127.0.0.1:8000"
HttpRequest.get_port()[source]
使用 META 中 HTTP_X_FORWARDED_PORT 和 SERVER_PORT 的信息返回請求的始發端口。
HttpRequest.get_full_path()[source]
返回包含完整參數列表的 path。例如:/music/bands/the_beatles/?print=true
HttpRequest.build_absolute_uri(location)[source]
返回 location 的絕對 URI 形式。 若是 location 沒有提供,則使用request.get_full_path()的值。
例如:"https://example.com/music/bands/the_beatles/?print=true"
HttpRequest.get_signed_cookie(key, default=RAISE_ERROR, salt='',max_age=None)[source]
從已簽名的 Cookie 中獲取值,若是簽名不合法則返回django.core.signing.BadSignature。
HttpRequest.is_secure()[source]
若是使用的是 Https,則返回 True,表示鏈接是安全的。
HttpRequest.is_ajax()[source]
若是請求是經過 XMLHttpRequest 生成的,則返回 True。
這個方法的做用就是判斷,當前請求是否經過 ajax 機制發送過來的。
HttpRequest.read(size=None)[source]
HttpRequest.readline()[source]
HttpRequest.readlines()[source]
HttpRequest.xreadlines()[source]
HttpRequest.iter()
上面的幾個方法都是從 HttpRequest 實例讀取文件數據的方法。
在 HttpRequest 對象中,GET 和 POST 屬性都是一個 django.http.QueryDict 的實例。也就是說你能夠按本文下面提供的方法操做 request.POST 和 request.GET。
request.POST 或 request.GET 的 QueryDict 都是不可變,只讀的。
若是要修改它,須要使用QueryDict.copy()方法,獲取它的一個拷貝,而後在這個拷貝上進行修改操做。
QueryDict 實現了 Python 字典數據類型的全部標準方法,由於它是字典的子類。
不一樣之處在於下面:
1.1 QueryDict 實例化方法。注意:QueryDict 的鍵值是能夠重複的!
>>> QueryDict('a=1&a=2&c=3') <QueryDict: {'a': ['1', '2'], 'c': ['3']}>
1.2. 循環可迭代對象中的每一個元素做爲鍵值,並賦予一樣的值(來至 value 參數)。
>>> QueryDict.fromkeys(['a', 'a', 'b'], value='val') <QueryDict: {'a': ['val', 'val'], 'b': ['val']}>
1.3. QueryDict.update(other_dict)
用新的 QueryDict 或字典更新當前 QueryDict。相似 dict.update(),可是追加內容,而不是更新並替換它們。 像這樣:
>>> q = QueryDict('a=1', mutable=True) >>> q.update({'a': '2'}) >>> q.getlist('a') ['1', '2']
1.4. QueryDict.items()
相似 dict.items(),若是有重複項目,返回最近的一個,而不是都返回:
>>> q = QueryDict('a=1&a=2&a=3') >>> q.items() [('a', '3')]
1.5. QueryDict.values()
相似 dict.values(),可是隻返回最近的值。 像這樣:
>>> q = QueryDict('a=1&a=2&a=3') >>> q.values() ['3']
1.6. QueryDict.copy()[source]
使用 copy.deepcopy()返回 QueryDict 對象的副本。 此副本是可變的!
1.7. QueryDict.getlist(key, default=None)
返回鍵對應的值列表。 若是該鍵不存在而且未提供默認值,則返回一個空列表。
1.8. QueryDict.setlist(key, list_)[source]
爲 list_設置給定的鍵。
1.9. QueryDict.appendlist(key, item)[source]
將鍵追加到內部與鍵相關聯的列表中。
1.10. QueryDict.setdefault(key, default=None)[source]
相似 dict.setdefault(),爲某個鍵設置默認值。
1.11. QueryDict.setlistdefault(key, default_list=None)[source]
相似 setdefault(),除了它須要的是一個值的列表而不是單個值。
1.12. QueryDict.lists()
相似 items(),只是它將其中的每一個鍵的值做爲列表放在一塊兒。 像這樣:
>>> q = QueryDict('a=1&a=2&a=3') >>> q.lists() [('a', ['1', '2', '3'])]
1.13. QueryDict.pop(key)[source]
返回給定鍵的值的列表,並從 QueryDict 中移除該鍵。 若是鍵不存在,將引起KeyError。 像這樣:
1.14. QueryDict.popitem()[source]
刪除 QueryDict 任意一個鍵,並返回二值元組,包含鍵和鍵的全部值的列表。在一個空的字典上調用時將引起 KeyError。 像這樣:
>>> q = QueryDict('a=1&a=2&a=3', mutable=True) >>> q.popitem() ('a', ['1', '2', '3'])
1.15. QueryDict.dict()
將 QueryDict 轉換爲 Python 的字典數據類型,並返回該字典。若是出現重複的鍵,則將全部的值打包成一個列表,做爲新字典中鍵的值。
>>> q = QueryDict('a=1&a=3&a=5') >>> q.dict() {'a': '5'}
1.16. QueryDict.urlencode(safe=None)[source]
以 url 的編碼格式返回數據字符串。 像這樣:
>>> q = QueryDict('a=2&b=3&b=5') >>> q.urlencode() 'a=2&b=3&b=5'
QueryDict 類型的對象
包含 get 請求方法的全部參數
與 url 請求地址中的參數對應,位於?後面
參數的格式是鍵值對,如 key1=value1
多個參數之間,使用&鏈接,如 key1=value1& key2=value2
鍵是開發人員定下來的,值是可變的
具體示例參堂代碼。
QueryDict 類型的對象
包含 post 請求方式的全部參數
與 form 表單中的控件對應
控件要有 name 屬性,name 屬性的值爲鍵,其 value 屬性的值爲值,構成鍵值對提交
鍵是開發人員定下來的,值是可變的具體示例參見課堂代碼。
會話過時時間
1.set_expiry(value):設置會話的超時時間
2.若是沒有指定,則兩個星期後過時
3.若是 value 是一個整數,會話將在 values 秒沒有活動後過時
4.若是 value 是一個 timedelta 對象(時間間隔),會話將在當前時間上加上這個指定的日期/時間過時
5.若是 value 爲 0,那麼用戶會話的 cookie 將在用戶的瀏覽器關閉時過時
6. 若是 value 爲 None,那麼會話永不過時