Django視圖層

1. 視圖函數

  • 視圖函數,簡稱視圖,是一個簡單的Python函數,它接受Web請求而且返回Web響應,本質就是一個函數
  • 視圖的參數
    • 一個HTTPResponse實例
    • 經過正則表達式組獲取的位置參數
    • 經過正則表達式組獲取的關鍵字參數
  • 在應用目錄下默認有views.py文件, 通常視圖都定義在此文件中
  • 若是處理功能過多,可將函數定義到不一樣的py文件中
  • 視圖的對象
    • HTTPResponse對象
    • HTTPRequest對象

2. HTTPRequest對象

HTTP應用的信息是經過 請求報文 和 響應報文 傳遞的,其中 請求報文 由客戶端發送,其中包含和許多的信息,而 django 將這些信息封裝成了 HttpRequest 對象,該對象由 HttpRequest 類建立。每個請求都會生成一個 HttpRequest 對象,django會將這個對象自動傳遞給響應的視圖函數,通常視圖函數約定俗成地使用 request 參數承接這個對象。php

2.1 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
    • 一個字符串,表示請求的路徑組件(不含域名)。
  5. HTTPRequest.method
    • 一個字符串,表示請求使用的HTTP 方法。必須使用大寫。
  6. HTTPRequest.encoding
    • 一個字符串,表示提交的數據的編碼方式(若是爲 None 則表示使用 DEFAULT_CHARSET 的設置,默認爲 'utf-8')。
    • 屬性是可寫的,你能夠修改它來修改訪問表單數據使用的編碼。接下來對屬性的任何訪問(例如從 GET 或 POST 中讀取數據)將使用新的 encoding 值。
    • 若是知道表單數據的編碼不是 DEFAULT_CHARSET ,則使用它。
  7. HTTPRequest.META
    • 一個標準的Python 字典,包含全部的HTTP 首部。具體的頭部信息取決於客戶端和服務器
  8. HTTPRequest.FILES
    • 一個相似於字典的對象,包含全部的上傳文件信息。
    • FILES 中的每一個鍵爲<input type="file" name="" />中的name,值則爲對應的數據。
    • FILES 只有在請求的方法爲POST 且提交的<form> 帶有enctype="multipart/form-data" 的狀況下才會包含數據。不然,FILES 將爲一個空的相似於字典的對象。
    • filename: 上傳文件名,用字符串表示
      content_type: 上傳文件的Content Type
      content: 上傳文件的原始內容
  9. HTTPRequest.COOKIES
    • 一個標準的Python 字典,包含全部的cookie。鍵和值都爲字符串。
  10. HTTPRequest.session
    • 一個既可讀又可寫的相似於字典的對象,表示當前的會話。只有當Django 啓用會話的支持時纔可用。
  11. HttpRequest.user(用戶認證組件下使用)
    待整理
  12. HttpRequest.path_info
    • 一個字符串,在某些 Web 服務器配置下,主機名後的 URL 部分被分紅腳本前綴部分和路徑信息部分。path_info 屬性將始終包含路徑信息部分,不論使用的Web 服務器是什麼。使用它代替 path 可讓代碼在測試和開發環境中更容易地切換。
  13. request.path 與 request.get_full_path()
  1. ''' 
  2. 請求url:http://127.0.0.1:8000/index.html/23?a=1 
  3. ''' 
  4. request.path :  
  5. request.path結果爲:/index.html/23 
  6.  
  7. request.get_full_path() 
  8. request.get_full_path()結果爲:/index.html/23?a=1 

2.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') 裝飾你的視圖以讓響應可以正確地緩存。

3. HTTPResponse對象

響應對象主要有三種形式:html

  • HTTPResponse()
  • render()
  • rendiret()

3.1 HTTPResponse()

HTTPResponse返回響應的字符串,對於HttpRequest請求對象來講,是由django自動建立的,可是,HttpResponse響應對象就必須咱們本身建立。每一個view請求處理方法必須返回一個HttpResponse響應對象。HttpResponse類在django.http.HttpResponse。render和redirect是在HTTPResponse對象上擴展的經常使用方法.python

3.1 render()

將一個模板頁面中的模板語法進行渲染,最終渲染成一個html靜態文件做爲響應體返回給瀏覽器ajax

  1. render(request, template_name[, context]) 
  2. ''' 
  3. 結合一個給定的模板和一個給定的上下文字典,並返回一個渲染後的 HttpResponse 對象。 
  4. ''' 

參數:
- request: 用於生成響應的請求對象。
- template_name:要使用的模板的完整名稱,可選的參數
- context:添加到模板上下文的一個字典。默認是一個空字典。若是字典中的某個值是可調用的,視圖將在渲染模板以前調用它
- content_type:生成的文檔要使用的MIME類型。默認爲DEFAULT_CONTENT_TYPE 設置的值。
- status:響應的狀態碼。默認爲200。正則表達式

3.2 redirect()

參數:數據庫

  • 一個模型:將調用模型的get_absolute_url() 函數
  1.  
  2. def my_view(request): 
  3. ... 
  4. object = MyModel.objects.get(...) 
  5. return redirect(object) 
  • 一個視圖,能夠帶有參數:將使用urlresolvers.reverse 來反向解析名稱
  1. def my_view(request): 
  2. ... 
  3. return redirect('some-view-name', foo='bar'
  • 一個絕對的或相對的URL,將原封不動的做爲重定向的位置。
  1. # 硬編碼URL 
  2. def my_view(request): 
  3. ... 
  4. return redirect('/some/url/'
  1. # 完整URL 
  2. def my_view(request): 
  3. ... 
  4. return redirect('http://example.com/'
  • 默認返回一個臨時的重定向;傳遞permanent=True 能夠返回一個永久的重定向。
  1. def my_view(request): 
  2. ... 
  3. object = MyModel.objects.get(...) 
  4. return redirect(object, permanent=True)   

3.3 render與redirect

render: 只是返回頁面內容,可是未發送第二次請求
redirect: 發送了第二次請求,url更新
django


總結:

  • render返回一個登錄成功後的頁面,刷新該頁面將恢復到跳轉前頁面。而redirect則不會
  • 若是頁面須要模板語言渲染,須要的將數據庫的數據加載到html,那麼render方法則不會顯示這一部分,render返回一個登錄成功頁面,不會通過url路由分發系統,也就是說,不會執行跳轉後url的視圖函數。這樣,返回的頁面渲染不成功;而redirect是跳轉到指定頁面,當登錄成功後,會在url路由系統進行匹配,若是有存在的映射函數,就會執行對應的映射函數。

3.4 301和302以及重定向

  1. 1. 301和302的區別 
  2. - 共同點:  
  3. 301和302狀態碼都表示重定向,就是說瀏覽器在拿到服務器返回的這個狀態碼後會自動跳轉到一個新的URL地址,這個地址能夠從響應的Location首部中獲取(用戶看到的效果就是他輸入的地址A瞬間變成了另外一個地址B)——這是它們的共同點。 
  4. - 不一樣點: 
  5. 1. 301表示舊地址A的資源已經被永久地移除了(這個資源不可訪問了),搜索引擎在抓取新內容的同時也將舊的網址交換爲重定向以後的網址; 
  6. 2. 302表示舊地址A的資源還在(仍然能夠訪問),這個重定向只是臨時地從舊地址A跳轉到地址B,搜索引擎會抓取新的內容而保存舊的網址。SEO302好於301. 
  7.  
  8. 2. 重定向緣由: 
  9. 1. 網站調整(如改變網頁目錄結構); 
  10. 2. 網頁被移到一個新地址; 
  11. 3. 網頁擴展名改變(如應用須要把.php改爲.Html或.shtml)。 
  12. - 這種狀況下,若是不作重定向,則用戶收藏夾或搜索引擎數據庫中舊地址只能讓訪問客戶獲得一個404頁面錯誤信息,訪問流量白白喪失; 
  13. - 再者某些註冊了多個域名的網站,也須要經過重定向讓訪問這些域名的用戶自動跳轉到主站點等。 
相關文章
相關標籤/搜索