Django知識總結(一)

壹 ● 有關http協議

一 ● 全稱

超文本傳輸協議(HyperText Transfer Protocol)

 

二 ● 協議

雙方遵循的規範 http協議是屬於應用層的協議(還有ftp, smtp等), 即瀏覽器請求消息和服務器響應消息的一系列規則

 

三 ● http協議的特性

http是無狀態、無鏈接的協議(stateless, connectionless protocol)的

http協議不具有保存以前發送過的請求或響應的功能-- 服務器中沒有保存客戶端的狀態，客戶端必須每次帶上本身的狀態去請求服務器

 

四 ● ※ 爲何http是無狀態協議的?

① TCP協議是基於鏈接和三次握手的，雖然具備可靠性， 但具備必定的缺陷。但試想一下，普通的C/S架構軟件， 頂多上千個Client同時鏈接，而對於B/S架構的網站， 十萬人同時在線也是很日常的事兒。 若是十萬個客戶端和服務器一直保持鏈接狀態，那服務器如何知足承載呢？   ② 基於上述問題，http協議應運而生。 基於TCP的可靠性鏈接，瀏覽器發出請求以後，服務器端當即關閉鏈接、釋放資源。 這樣既保證了資源可用，也吸收了TCP的可靠性的優勢。 所以，一般說http協議是"無狀態"的。

 

五 ● ※ 保持http鏈接狀態的技術--session tracking(會話跟蹤)

經常使用的會話跟蹤技術是cookie與session cookie是在客戶端記錄用戶信息的鍵值對 session是在服務器端記錄用戶信息的鍵值對

如今一些輕量級的web庫，用的是加密的cookie，不須要session。 python的tornado框架就沒有session，只有加密的cookie。

 

六 ● http消息

1 ● 瀏覽器發出的請求消息(request)

請求首行 status-line 請求頭 request headers \r\n\r\n空行 請求體 request body(例如, 用戶名, 密碼)   也就是: [請求方法] [URL] [http協議版本] [頭字段1]: 值1 [頭字段2]: 值2   [請求體]

※ GET有沒有請求體? 通常來講, GET請求沒有請求體, 但也能夠有, 詳見: https://unmi.cc/why-http-get-cannot-sent-data-with-reuqest-body/   ※ 請求頭的頭字段包括Content-Type, User-Agent, Cookie, Accept-Language等, 詳見: https://www.cnblogs.com/jiangxiaobo/p/5499488.html

 

※ GET請求和POST請求的區別

1, ① GET請求通常經過 URL 以 Query Parameter 的形式來發送數據, 例如： https://www.douban.com/group/explore?tag=%E6%97%85%E8%A1%8C () ② GET 請求長度限制爲1K; ③ GET 請求可被緩存   2, ① POST 請求通常經過消息體發送數據, 例如: ② POST 請求對數據長度沒有限制 ③ POST 請求不會被緩存

※ GET請求的其它特徵: GET 請求保留在瀏覽器歷史記錄中 GET 請求可被收藏爲書籤 GET 請求不該在處理敏感數據時使用 GET 請求只應當用於取回數據   ※ POST請求的其它特徵: POST 請求不會保留在瀏覽器歷史記錄中 POST 不能被收藏爲書籤   ※ 其餘 HTTP 請求方法(瞭解) HEAD: 與 GET 相同，但只返回 HTTP 報頭，不返回文檔主體。 PUT: 上傳指定的 URI 表示。 DELETE: 刪除指定資源。 OPTIONS: 返回服務器支持的 HTTP 方法。 CONNECT: 把請求鏈接轉換到透明的 TCP/IP 通道。

 

※ 請求消息案例

GET請求消息:   POST請求消息:   ※ 請求頭能夠有cookie, 例如:

 

※ HttpRequest & HttpResponse中常見的四種ContentType/的POST 提交數據方式對應的四種常見Content-Type取值

※ Content-Type又叫Mime-Type(Multipurpose Internet Mail Extensions--多用途互聯網郵件擴展類型) ※ HTTP Content-type的總表: http://tool.oschina.net/commons/

application/x-www-form-urlencoded 這應該是最多見的 POST 提交數據的方式了。瀏覽器的原生 form 表單，若是不設置 enctype 屬性，那麼默認以 application/x-www-form-urlencoded 方式提交數據。請求相似於下面這樣（無關的請求頭在本文中都省略掉了）：   POST http://www.example.com HTTP/1.1 Content-Type: application/x-www-form-urlencoded;charset=utf-8   title=test&sub%5B%5D=1&sub%5B%5D=2&sub%5B%5D=3   首先，Content-Type 被指定爲 application/x-www-form-urlencoded；其次，提交的數據按照 key1=val1&key2=val2 的方式進行編碼，key 和 val 都進行了 URL 轉碼。大部分服務端語言都對這種方式有很好的支持。 不少時候，咱們用 Ajax 提交數據時，也是使用這種方式。例如 JQuery 和 QWrap 的 Ajax，Content-Type 默認值都是「application/x-www-form-urlencoded;charset=utf-8」。   ② multipart/form-data ③ application/json ④ text/xml

注意: ① Content-Type通常只存在於POST方法中，由於GET方法請求參數都會被編碼到url後面，因此在GET方法中加Content-ype是無用的。 ② 若是使用的是POST方式，而且數據是由from表單提交，那麼就必須把content-Type設爲application/x-www-form-urlencoded（也能夠不指定Content-Type, 由於Content-Type默認是application/x-www-form-urlencoded），不然後臺是沒法接收到數據的。 ③ HTTP請求消息和響應消息的數據類型都是Content-Type; 不過, 在jQuery ajax中, 發送至服務器的數據類型寫做"contentType", 服務器返回的數據類型寫做"dataType": contentType 類型：String 默認值: "application/x-www-form-urlencoded"。發送信息至服務器時內容編碼類型。 默認值適合大多數狀況。若是你明確地傳遞了一個 content-type 給 $.ajax() 那麼它一定會發送給服務器（即便沒有數據要發送）。 dataType 類型：String 預期服務器返回的數據類型。若是不指定，jQuery 將自動根據 HTTP 包 MIME 信息來智能判斷，好比 XML MIME 類型就被識別爲 XML。在 1.4 中，JSON 就會生成一個 JavaScript 對象，而 script 則會執行這個腳本。隨後服務器端返回的數據會根據這個值解析後，傳遞給回調函數。可用值: "xml": 返回 XML 文檔，可用 jQuery 處理。 "html": 返回純文本 HTML 信息；包含的 script 標籤會在插入 dom 時執行。 "script": 返回純文本 JavaScript 代碼。不會自動緩存結果。除非設置了 "cache" 參數。注意：在遠程請求時(不在同一個域下)，全部 POST 請求都將轉爲 GET 請求。（由於將使用 DOM 的 script標籤來加載） "json": 返回 JSON 數據。 "jsonp": JSONP 格式。使用 JSONP 形式調用函數時，如 "myurl?callback=?" jQuery 將自動替換 ? 爲正確的函數名，以執行回調函數。 "text": 返回純文本字符串   詳見: http://www.w3school.com.cn/jquery/ajax_ajax.asp

※ HTML <form> 標籤的 enctype 屬性 enctype 屬性規定在發送到服務器以前應該如何對錶單數據進行編碼。 默認地，表單數據會編碼爲 "application/x-www-form-urlencoded"。就是說，在發送到服務器以前，全部字符都會進行編碼（空格轉換爲 "+" 加號，特殊符號轉換爲 ASCII HEX 值）。 <form action="form_action.asp" enctype="text/plain"> <p>First name: <input type="text" name="fname" /></p> <p>Last name: <input type="text" name="lname" /></p> <input type="submit" value="Submit" /> </form>   enctype 屬性的值: ① application/x-www-form-urlencoded：在發送前編碼全部字符（默認） ② multipart/form-data：不對字符編碼。用表單上傳文件時, 必須使用該值。 ③ text/plain：空格轉換爲 "+" 加號，但不對特殊字符編碼。

 

※ 狀態碼

1XX:信息性狀態碼 2XX:成功狀態碼,200表示請求成功, 通常用於GET與POST請求 3XX:重定向狀態碼 4XX:客戶端錯誤狀態碼,404表示沒有找到請求的資源 5XX:服務器端錯誤狀態碼,500表示內部錯誤

詳見: http://www.runoob.com/http/http-status-codes.html

 

 

2● 服務器發出的響應消息(response)

響應首行status-line 響應頭 request headers \r\n\r\n 空行 響應體 response body   也就是: [http協議版本] [狀態碼] [描述信息] [頭字段1]: 值1 [頭字段2]: 值2 /r/n/r/n [請求體]

案例:

 

七 ● tcp和http的區別和聯繫

傳輸層的TCP是基於網絡層的IP協議的， 而應用層的HTTP協議又是基於傳輸層的TCP協議的， 而Socket自己不算是協議，它只是提供了一些使用TCP/UDP編程的接口，例如create()，listen()，connect()，accept()，send()，read()和write()等等

兩種網絡構架: ① C/S架構--例如安卓手機上的原生APP ② B/S架構--例如安卓手機上的Web APP

 

八 ● web應用涉及的過程

一個請求/處理/響應的過程: ① 瀏覽器先向服務器發送請求 ② 服務器接收到請求後，作相應的處理，而後封裝好響應報文，再回送給瀏覽器 ③ 瀏覽器拿到響應報文後，再經過瀏覽器引擎去渲染網頁(其實就是字符串替換)，解析DOM樹 ④ javascript引擎解析並執行腳本操做，插件去幹插件該乾的事兒 詳見: http://kb.cnblogs.com/page/129756/

 

九 ● web應用的本質

一個socket服務端→用戶的瀏覽器其實就是一個socket客戶端

 

十 ● HTTP通訊傳輸過程

 

●

 

 

 

貳 ● MVC

● 定義

※ MVC框架的核心思想--解耦 ① m表示model，負責與數據庫進行交互 最底下的一層→是核心的"模型層"（Model），也就是程序須要操做的數據或信息→ 用於封裝與應用程序的業務邏輯相關的數據以及對數據的處理方法。"Model"有對數據直接訪問的權力，例如對數據庫的訪問。   ② v表示view，用於向用戶展現結果 最上面的一層→是直接面向最終用戶的"視圖層"（View）→是提供給用戶的操做界面，是程序的外殼。   ③ c表示controller，是核心，負責處理請求、獲取數據、返回結果 中間的一層→是"控制層"（Controller），它根據用戶從"視圖層"輸入的指令，選取"模型層"中的數據， 而後對其進行相應的操做，產生最終結果。

 

●

 

 

叄 ● MTV

一 ● 定義

※ 在django, 控制器接收用戶輸入的部分由框架自行處理, 因此django更關注的是模型(model), 模板(template)和視圖(view) ① m表示model，負責與數據庫進行交互 ② v表示view，是核心，負責處理請求、獲取數據、返回結果 ③ t表示template，負責呈現內容到瀏覽器

三者的關係: 視圖函數, 使得模型類和模板銜接起來.

 

二 ● 前端和後端進行數據交互的3種方式

1, a標籤 2, form表單 3, ajax

以form的驗證思路爲例: 前端：提交form表單 後臺：建立form類，當請求到來時，先匹配，匹配出正確和錯誤信息。

 

 

肆 ● Django框架執行流程圖

1, 客戶端的瀏覽器發起一個url請求; 2, 路由配置(URLconf)根據URL匹配view.py裏對應的視圖函數, 當有緩存頁面的時候直接返回內容。 3, 視圖函數執行所請求的操做, 一般包括從Models裏讀取數據; 4, Models將數據返回給視圖; 5, 視圖將要展現的數據返回給template模板.

 

 

伍 ● Django的安裝

# pip 安裝 pip install Django==1.10 # 克隆下載最新版本 git clone https://github.com/django/django.git # 導入django模塊 >>> import django >>> print(django.get_version()) 1.10

 

陸 ● Django的基本命令

# 查看django版本 $ python -m django --version   # 建立項目,名爲mysite $ django-admin startproject mysite   # 啓動django $ python manage.py runserver $ python manage.py runserver 8080 $ python manage.py runserver 0.0.0.0:8000   # 建立應用程序，確保和 manage.py 是同一目錄 $ python manage.py startapp polls # 在setting.py的INSTALLED_APPS列表裏添加"polls"   # admin建立管理員用戶 $ python manage.py createsuperuser

python manger.py makemigrations 將model層轉換爲migration遷移文件--創建migrations目錄，並記錄下你全部的關於modes.py的改動，例如0001_initial.py，   python manger.py migrate 執行新版本的遷移文件，並更新數據庫, 生成表

 

柒 ● Django項目結構

命令: django-admin startproject helloDjango2 python manage.py startapp blog 目錄結構以下圖：

manage.py：一個命令行工具，可使你用多種方式對Django項目進行交互 內層的目錄：項目的真正的Python包 __init __.py：一個空文件，它告訴Python這個目錄應該被看作一個Python包 settings.py：項目的配置 urls.py：項目的URL聲明 wsgi.py：項目與WSGI兼容的Web服務器入口, 部署到ngix服務器上須要使用到的

 

● Django的處理流程/生命週期

1.用戶經過瀏覽器發送HTTP請求, 而後Django建立一個包含請求元數據的 HttpRequest對象 2. HttpRequest對象到達各個中間件，中間件對HttpRequest對象作預處理或者直接返回HttpResponse對象 3.若未返回HttpResponse對象，HttpRequest對象會到達URLconf路由，找到對應視圖(view)函數 4.視圖函數作相應的預處理或直接返回HttpResponse對象或HttpResponse子類對象. 5.視圖函數能夠選擇性的經過Models訪問底層的數據 6.視圖函數將數據返回給Django的模板系統，templates經過filter或tags把數據渲染到模板上 7.模板被渲染以後, Django將它做爲 HttpResponse對象返回到瀏覽器, 而後展現給用戶.

※ 幫助理解Django的處理流程的幾段話: ① Django將請求報文中的請求行、首部信息、內容主體封裝成 HttpRequest 類中的屬性。除了session外的全部屬性都應該認爲是隻讀 ② 通常視圖函數約定俗成地使用 request(而不是HttpRequest) 做爲形參來承接這個對象。 ③ 上述流程中最主要的幾個部分分別是：Middleware(每個中間件是一個類，包括request, view, exception, response)，URLConf(url映射關係)，Template(模板系統) ④ 當一個頁面被請示時，Django建立一個包含請求元數據的 HttpRequest 對象。而後Django調入合適的視圖，把 HttpRequest 做爲視圖函數的第一個參數傳入, 每一個視圖要負責返回一個 HttpResponse 對象或HttpResponse子類對象。   ⑤ 經常使用的HttpRequest屬性有HttpRequest.GET和HttpRequest.POST, 詳見: https://www.cnblogs.com/scolia/archive/2016/07/01/5633351.html ⑥ Django框架處理流程的核心在於中間件(middleware)，Django全部的請求、響應都由中間件來完成 ⑦ Middleware是"設計模式"裏的Decorator（裝飾器）。

 

●

 

●

 

 

捌 ● 視圖(函數)(V)

一 ● 定義

視圖函數（或視圖）是一個接受 Web 請求並返回 Web 響應的 Python 函數或類。   ※ 該響應能夠是一份網頁的 HTML 內容、一次重定向、一條 404 錯誤、一份 XML 文檔、一幅圖片，或其它任何東西。   視圖函數是存放應用邏輯的地方。它將從你以前建立的模型中獲取數據，並將它傳遞給模板。

 

二 ● FBV & CBV

基於函數的view，叫做FBV (function-based view)。 基於類的view，叫做CBV (class-based view)。

# FBV 寫法 # urls.py url(r'^login/$',views.login, name="login"),   # views.py def login(request): if request.method == "POST": print(request.POST)   return render(request,"login.html")   # HTML <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <meta name="viewport" content="width=device-width, initial-scale=1"> <title>登陸頁面</title> </head> <body> <form action="{% url 'login' %}" method="post" enctype="multipart/form-data"> <input type="text" name="user2"> <input type="file" name="file"> <input type="submit" value="提交"> </form> </body> </html>

# CBV 寫法 # urls.py url(r'^login/$',views.Login.as_view(), name="login"),   # views.py from django.views import View class Login(View): # 類首字母大寫 def get(self,request): return render(request,"login.html") def post(self,request): print(request.POST) return HttpResponse("OK")

 

●

 

 

三 ● HttpRequest對象 & HttpResponse對象

當一個頁面被請示時，Django建立一個包含請求元數據的HttpRequest 對象； 而後Django調入合適的視圖，把 HttpRequest 做爲視圖函數的第一個參數傳入； 每一個視圖要負責返回一個HttpResponse對象或HttpResponse子類對象。

詳見: http://python.usyiyi.cn/translate/django_182/ref/request-response.html

 

四 ● HttpRequest對象

HttpRequest 表示來自某客戶端的一個單獨的HTTP請求。 HttpRequest實例的屬性包含了關於這次請求的大多數重要信息；除了session外的全部屬性都應該認爲是隻讀的。

須要記住的HttpRequest對象的屬性: method、GET、POST、COOKIES、session、files、user、body、path

① HttpRequest.method 一個字符串，表示請求使用的HTTP 方法。必須使用大寫。例如： if request.method == 'GET': do_something() elif request.method == 'POST': do_something_else() ※ form 的 method="post" (post必須小寫), 可是request.method=="POST"和request.POST中的POST又必須大寫.   ② HttpRequest.GET 一個相似於字典的對象(django.http.QueryDict類的實例)，包含HTTP GET 的全部參數   ③ HttpRequest.POST 一個包含全部給定的HTTP POST參數的類字典對象(django.http.QueryDict類的實例)，提供了包含表單數據的請求。 若是須要訪問請求中的原始或非表單數據，可使用HttpRequest.body 屬性。   POST 請求能夠帶有空的POST 字典 —— 若是經過HTTP POST 方法請求一個表單可是沒有包含表單數據的話。所以，不該該使用if request.POST 來檢查使用的是不是POST 方法；應該使用if request.method == "POST"。   注意：POST 不包含上傳的文件信息。參見FILES。   ④ HttpRequest.COOKIES 一個標準的Python 字典，包含全部的cookie。鍵和值都爲字符串。 request.COOKIES['sessionid'] # 獲取 request.COOKIES.get('sessionid', None) # 獲取   ※對COOKIES的設置經過HttpResponse對象的set_cookie()方法來完成   ⑤ HttpRequest.session 一個既可讀又可寫(只有session可寫)的相似於字典的對象，表示當前的會話。只有當Django 啓用會話的支持時纔可用。 fav_color = request.session['fav_color'] #get request.session['fav_color'] = 'blue' #set del request.session['fav_color'] #del 'fav_color' in request.session #contains fav_color = request.session.get('fav_color', 'red') #get fav_color = request.session.pop('fav_color') # pop     ⑥ HttpRequest.FILES 一個相似於字典的對象，包含全部的上傳文件。 FILES 中的每一個鍵爲<input type="file" name="" /> 中的name。   注意，FILES 只有在請求的方法爲POST 且提交的<form> 帶有enctype="multipart/form-data" 的狀況下才會包含數據。不然，FILES 將爲一個空的相似於字典的對象。   ⑦ 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. ※ HttpResponse.user 只有當Django 啓用AuthenticationMiddleware 中間件時纔可用。 ※ AUTH_USER_MODEL在settings.py中設置, 例如 AUTH_USER_MODEL = "blog.UserInfo" # 覆蓋默認的User模型, # 注意：UserInfo表繼承了AbstractUser，須要在settings 中寫入：AUTH_USER_MODEL ="應用名.UserInfo"   ⑧ HttpRequest.body 一個字符串，表明請求報文的主體。在處理非 HTTP 報文時很是有用，例如：二進制圖片、XML,Json等。 可是，若是要處理表單數據的時候，推薦仍是使用 HttpRequest.POST 。 另外，咱們還能夠用 python 的類文件方法去操做它，詳情參考 HttpRequest.read() 。 HttpRequest.body的形式: b'name=Arroz'   HttpRequest.POST的形式: <QuerySet: {'name': ['Arroz']}> # 更容易取值   ⑨ HttpRequest.path 一個字符串，表示請求的頁面的完整路徑，不包含域名。 例如："/music/bands/the_beatles/"

HttpRequest對象的方法: ① HttpRequest.get_host() ② HttpRequest.get_full_path() print(request.path) # /login/ print(request.get_host()) # 127.0.0.1:8000 print(request.get_full_path()) # /login/?name=Arroz   ③ HttpRequest.get_signed_cookie(key, default=RAISE_ERROR, salt='', max_age=None) ④ HttpRequest.is_secure() ⑤ HttpRequest.is_ajax()

 

五 ● HttpResponse對象

與由Django自動建立的HttpRequest對象相比，HttpResponse對象是咱們的職責範圍了。咱們寫的每一個視圖都須要實例化，填充和返回一個HttpResponse對象或HttpResponse子類對象。   ※ 下面兩個引入的HttpResponse類是同樣的 from django.http import HttpResponse from django.shortcuts import render, HttpResponse, redirect

① 傳遞字符串 from django.http import HttpResponse response = HttpResponse("Here's the text of the Web page.") # 實例化 response = HttpResponse("Text only, please.", content_type="text/plain")   ② 設置或刪除響應頭信息 response = HttpResponse() response['Content-Type'] = 'text/html; charset=UTF-8'   del response['Content-Type']   ③ 經常使用屬性 HttpResponse.content: 響應內容, bytes格式 HttpResponse.charset: 響應內容的編碼 HttpResponse.status_code: 響應的狀態碼 HttpResponse.streaming: 這個屬性永遠爲假，通常用於中間件 HttpResponse.closed: 關閉 例如: def post(request): res=HttpResponse("OK") print(res.content) # b'ok' print(res.charset) # utf-8 print(res.status_code) # 200 return res     ④經常使用方法 HttpResponse.set_cookie(key, value='', max_age=None, expires=None, path='/', domain=None, secure=None, httponly=False) # 設置一個cookie   HttpResponse.set_signed_cookie(key, value, salt='', max_age=None, expires=None, path='/', domain=None, secure=None, httponly=True) # 設置加密的cookie(加鹽的cookie)   HttpResponse.delete_cookie(key, path='/', domain=None) #刪除Cookie與給定鍵。   ※參數說明: key, # 鍵 value='', # 值 max_age=None, # 超時時間 expires=None, # 超時時間(IE requires expires, so set it if hasn't been already.) path='/', # Cookie生效的路徑，/ 表示根路徑，特殊的：跟路徑的cookie能夠被任何url的頁面訪問 domain=None, # Cookie生效的域名 secure=False, # 採用https傳輸 httponly=False # 只能http協議傳輸，沒法被JavaScript獲取（不是絕對，底層抓包能夠獲取到也能夠被覆蓋）   ※因爲cookie保存在客戶端的電腦上，因此，JavaScript和jquery也能夠操做cookie，例如: // 建立一個cookie並設置cookie的有效路徑： $.cookie('cookieName', 'cookieValue', {expires: 7, path: '/'});

 

六 ● JsonResponse對象

JSON(JavaScript Object Notation) 是一種輕量級的數據交換格式，主要用於傳送數據。 JsonResponse是HttpResponse的子類，專門用來生成JSON編碼的response。

from django.http import JsonResponse   response = JsonResponse({'foo': 'bar'}) print(response.content) # b'{"foo": "bar"}'   # 默認只能傳遞字典類型，若是要傳遞非字典類型須要設置一下safe關鍵字參數。 response = JsonResponse([1, 2, 3], safe=False)

 

●

 

 

玖 ● URLconf, 路由配置 (做爲V的一部分)

※ router, 路由, 安排路線的人 ※ 請求的url被看作是一個普通的python字符串，進行匹配時不包括get或post請求的域名、端口和參數   urlpatterns = [] #裏面存放着一個個url()對象 / 一個個url映射元素 / 一條條的路由映射關係.   url()函數 url(正則表達式, view視圖函數，參數[可選]，別名[可選]) 例如: url(r'^archive-summary/(\d{4})/$', archive, {'summary': True}, "arch-summary"),   參數說明： 參數: 可選的、要傳遞給視圖函數的默認參數（字典形式）   ※ 被圓括號包圍的正則表達式組（group）會捕獲URL 中的值並做爲位置參數傳遞給視圖函數。

 

 

一 ● url()函數的兩種語法

語法一：url(正則,'view函數') 指定正則和視圖的對應關係 在應用內部建立urls.py文件，指定請求地址與視圖的對應關係 說明1：正則部分推薦使用r，表示字符串不轉義，這樣在正則表達式中使用\只寫一個就能夠 說明2：不能在開始加反斜槓，推薦在結束加反斜槓   語法二：url(正則,include('應用.urls')) 把每一個應用的 URL 寫在它們各自的 urls.py 配置文件裏，而後在項目文件下的 urls.py 裏用 include() 函數引用: 例如: url(r'^violet/', include('violet.urls')),  #這裏引入應用 violet 下的 urls.py 配置文件; 以violet/開頭的url被轉接到violet.urls.py文件, django會把url字符串前面被正則表達式匹配到的r'^violet/'砍掉（chop off），剩下的string傳遞到include的urls中進行進一步匹配。   再如: url(r'^admin/', include(admin.site.urls))

 

二 ● url映射(mapping)的解析

補充: ① url請求樣式也叫做"url"標籤 ② url標籤也能夠寫成: {% url 'user_detail' user.id %}, 此時url元素的第一個參數應該是r'^user/detail/([0-9]+)/$', /user/detail/1 ③ 若是url匹配時攜帶參數(例如上面的有名分組"(?P<pk>[0-9]+)"), 那麼，在匹配到視圖時就須要傳入一個參數(例如上面user_detail函數的參數"pk"), 在頁面中的url反向解析，也要傳入對應參數(例如上面url標籤中的"pk=user.id")   ※ 有名分組和無名分組的案例: 無名分組： # url(r'^articls/(\d{4})/(\d{2})$', views.archive3,), # archive2(request,2000,11) 有名分組： # url(r'^articls/(?P<y>\d{4})/(?P<m>\d{2})$', views.archive4,), # archive2(request,y=2000,m=11)

URL的映射的解析有兩種： ① 通常的url解析: 由客戶端的瀏覽器發起一個url請求，Django根據URLconf，把url中的參數捕獲，調用相應的視圖，獲取相應的數據，而後返回給客戶端顯示. () ② url反向解析:經過一個視圖的別名，加上一些參數和值(若是有的話)，逆向獲取相應的URL經過url的別名, 能夠自動更新而不用遍歷項目的源代碼來搜索並替換過時的URL；(url反向解析也叫url逆向解析，url逆向匹配，url的逆向查閱，等)   Django提供了不一樣的層級的url反向向解析處理工具： ① 在模板templates中，使用url標記，如：{% url 'user_detail' pk=user.id %} ####art.html <h1>{{ day }}</h1> <a href="{% url 'app01-art' %}">點擊</a> #若url更改，則模板中的url引用也會隨着更改   ####urls.py from django.conf.urls import url,includefrom app01 import views urlpatterns = [ url(r'^art/', views.art3, name='app01-art'), ]   ####views.py def art3(request): return render(request,"art.html",{"day":"abc"})     ② 在Python代碼中，使用django.core.urlresolvers.reverse()方法 ####urls.py from django.conf.urls import url,includefrom app01 import views urlpatterns = [ url(r'^art/', views.art3, name='app01-art'), ]   ####views.py def art3(request): print(reverse('app01-art')) #在視圖函數中對url進行反向解析 return HttpResponse("OK")   ※ 還有一種url解析方案瞭解便可: 在更高層次處理model實例時，可使用get_absolute_url()方法

 

三 ● url的命名空間

爲各url起別名時要根據不一樣用途進行名稱上的區別，但當各應用不少，經過路由分發，各應用中的urls不免會有重複，所以要名稱空間，根據不一樣的應用創建不一樣的命名空間，不然當各url中有重名的，就只會找到最後一個加載的url. # 項目的urls.py from django.conf.urls import url, include from django.contrib import admin   urlpatterns = [ url(r'^admin/', admin.site.urls), url(r'^app01/', include('app01.urls', namespace="app01")), url(r'^app02/', include("app02.urls", namespace="app02")),]   # app01應用的urls.py文件 from django.conf.urls import url from app01 import views   urlpatterns = [ url(r'^index/', views.index, name="index"), ]   # app02應用的urls.py文件 from django.conf.urls import url from app02 import views   urlpatterns = [ url(r'^index/', views.index, name="index"), ]   # 狀況1: 在url標記中寫出命名空間: {% url 'app01:index' %}   # 狀況2: 在app02的視圖函數中反向解析app01中的url和app02中的url from django.shortcuts import render, HttpResponse from django.core.urlresolvers import reverse     def index(request): print(reverse("app01:index")) # /app01/index/   print(reverse("app02:index")) # /app02/index/ return HttpResponse("OK")

 

四 ● 視圖函數的3種返回值

from django.shortcuts import render, HttpResponse, redirect

1, render(request, template_name, context=None, content_type=None, status=None, using=None) # 返回HttpResponse對象 例如: a, return render(request, 'user/user_detail.html', {'data': user}) b, now=datetime.datetime.now() html="<html><body>如今時刻：<h1>%s.</h1></body></html>" %now return HttpResponse(html)   ① request: 是一個固定參數。 ② template_name: templates 中定義的文件, 要注意路徑名. 好比'templates\polls\index.html', 參數就要寫'polls\index.html' ③ context: 後臺返回給瀏覽器的、用於渲染的數據, 是字典格式,例如上面發的{'data': user}, data是自定義的指針名字, 它會被index.html引用(不是user_list) ④ status: 爲響應狀態代碼, 默認值爲200 ⑤ using: 用於加載模板使用的模板引擎的名稱。

2, HttpResponse(content= ' ', mimetype=DEFAULT_CONTENT_TYPE) # 返回HttpResponse對象 # content是字符串格式, mimetype指明的是消息內容類型,例如: a, return HttpResponse("登錄成功")   b, res = {" success": False, "error": ""} return HttpRepsponse(json.dumps(res), mimetype="application/json")   c, 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)   d, django下載文件, 詳見: http://blog.csdn.net/w6299702/article/details/38777165 response = HttpResponse(readFile(filepath_),content_type='APPLICATION/OCTET-STREAM') #設定文件頭，這種設定可讓任意文件都能正確下載，並且已知文本文件不是本地打開 response['Content-Disposition'] = 'attachment; filename='+filename_.encode('utf-8') + filetype_.encode('utf-8') #設定傳輸給客戶端的文件名稱 response['Content-Length'] = os.path.getsize(filepath_) #傳輸給客戶端的文件大小

3, redirect(to, permanent=False, *args, **kwargs) # 返回HttpResponseRedirect對象(HttpResponse的子類對象) # 默認狀況下，爲臨時重定向；經過 permanent=True 設置永久重定向, 例如: a, 傳遞一個視圖的名稱 def my_view(request): ... return redirect('some-view-name', foo='bar')   b, 傳遞要重定向到的一個具體的網址 def my_view(request): ... return redirect('/some/url/')   c, 傳遞一個完整的網址 def my_view(request): ... return redirect('http://example.com/')

※ 自Django1.3開始, render()方法是render_to_response的一個嶄新的快捷方式，前者會自動使用RequestContext, 然後者必須coding出來，這是最明顯的區別，固然前者更簡潔。   return render(request, 'blog_add.html', {'blog': blog, 'form': form, 'id': id, 'tag': tag}) return render_to_response('blog_add.html',{'blog': blog, 'form': form, 'id': id, 'tag': tag}, context_instance=RequestContext(request))   ※ locals()用法：locals()能夠直接將函數中全部的變量所有傳給模板。固然這可能會傳遞一些多餘的參數，有點浪費內存的可能。例如: return render(request, 'blog_add.html',locals())