一.路由配置系統 1.1 基本認識 a. URL配置(URLconf)就像Django 所支撐網站的目錄。它的本質是URL與要為該URL調用的視圖函數之間的映射表 b. URLconf 在請求的URL 上查找，將它當做一個普通的Python 字元串。不包括GET和POST參數以及功能變數名稱。例如，htt ...

一.路由配置系統

1.1 基本認識

　　a. URL配置(URLconf)就像Django 所支撐網站的目錄。它的本質是URL與要為該URL調用的視圖函數之間的映射表

　　b. URLconf 在請求的URL 上查找，將它當做一個普通的Python 字元串。不包括GET和POST參數以及功能變數名稱。

例如，http://www.example.com/myapp/ 請求中，URLconf 將查找myapp/。

在http://www.example.com/myapp/?page=3 請求中，URLconf 仍將查找myapp/。

URLconf 不檢查請求的方法。換句話講，所有的請求方法 —— 同一個URL的POST、GET、HEAD等等 —— 都將路由到相同的函數。

　　c. 每個捕獲的參數都作為一個普通的Python 字元串傳遞給視圖，無論正則表達式使用的是什麼匹配方式。

1.2 語法

urlpatterns = [
         url(正則表達式, views視圖函數，參數，別名)

1.3 基本用法

from django.conf.urls import url,include
from django.contrib import admin
from app01 import views

urlpatterns = [
    url(r'^admin/', admin.site.urls),         #不加$,匹配開頭
    url(r'^login/$', views.login),              #加$,完整匹配

#加括弧，將作為位置參數傳入view函數里
url(r'^articles/([0-9]{4})/$', views.year_archive),

url(r'^menu/(\d+)', views.menu), # menu(request,1)

'''
有名分組(named group)
將用"()"捕獲的URL中的值以關鍵字參數傳入view函數中
在Python 正則表達式中，命名正則表達式組的語法是(?P<name>pattern)，其中name 是組的名稱，pattern 是要匹配的模式。
'''
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),
]

'''
利用有名分組，給view參數設預設值
'''

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),
]

1.4 URL分發

'''
當有多個app,且url路徑較多時，為方便管理，可進行url分發
在app目錄中建立自己的urls,在共用urls文件中利用‘include’實現
'''
from django.conf.urls import include, url
urlpatterns = [
   url(r'^admin/', admin.site.urls),
   url(r'^blog/', include('blog.urls')),
]

1.5 URL反向解析

　　在使用Django 項目時，一個常見的需求是獲得URL 的最終形式，以用於嵌入到生成的內容中（視圖中和顯示給用戶的URL等）或者用於處理伺服器端的導航（重定向等）。

人們強烈希望不要硬編碼這些URL（費力、不可擴展且容易產生錯誤）或者設計一種與URLconf 毫不相關的專門的URL 生成機制，因為這樣容易導致一定程度上產生過期的URL。

換句話講，需要的是一個DRY 機制。除了其它有點，它還允許設計的URL 可以自動更新而不用遍歷項目的源代碼來搜索並替換過期的URL。

獲取一個URL 最開始想到的信息是處理它視圖的標識（例如名字），查找正確的URL 的其它必要的信息有視圖參數的類型（位置參數、關鍵字參數）和值。

Django 提供一個辦法是讓URL 映射是URL 設計唯一的地方。你填充你的URLconf，然後可以雙向使用它：

根據用戶/瀏覽器發起的URL 請求，它調用正確的Django 視圖，並從URL 中提取它的參數需要的值。
根據Django 視圖的標識和將要傳遞給它的參數的值，獲取與之關聯的URL。

第一種方式是我們在前面的章節中一直討論的用法。第二種方式叫做反向解析URL、反向URL 匹配、反向URL 查詢或者簡單的URL 反查。

在需要URL 的地方，對於不同層級，Django 提供不同的工具用於URL 反查：

在模板中：使用url 模板標簽。
在Python 代碼中：使用django.core.urlresolvers.reverse() 函數。
在更高層的與處理Django 模型實例相關的代碼中：使用get_absolute_url() 方法

#urls中
from django.conf.urls import url,include
from django.contrib import admin
from app01 import views

urlpatterns = [
    url(r'^admin/', admin.site.urls),
    url(r'^loginggggg/$', views.login,name='login'),

#templates中
<form action="{% url 'login' %}" method="post">

1.6 名稱空間(namespace)

二.視圖函數（views）

2.1 介紹

　　接受web請求併進行邏輯處理繼而返回web響應。

　　約定是將視圖放置在項目或應用程式目錄中的名為views.py的文件中。

2.2 請求對象

request作為views函數中的第一個參數使用

Request.body
'''
一個字元串，代表請求報文的主體。在處理非 HTTP 形式的報文時非常有用，例如：二進位圖片、XML,Json等。
　　但是，如果要處理表單數據的時候，推薦還是使用 HttpRequest.POST 。
　　另外，我們還可以用 python 的類文件方法去操作它，詳情參考 HttpRequest.read() 。
'''

Request.path
'''
一個字元串，表示請求的路徑組件（不含功能變數名稱）。
　　例如："/music/bands/the_beatles/"
'''

Request.method
'''
一個字元串，表示請求使用的HTTP 方法。必須使用大寫。
　　例如："GET"、"POST"
'''

Request.GET
'''
一個類似於字典的對象，包含 HTTP GET 的所有參數。詳情請參考 QueryDict 對象。
'''

Request.POST
'''
　　一個類似於字典的對象，如果請求中包含表單數據，則將這些數據封裝成 QueryDict 對象。
　　POST 請求可以帶有空的 POST 字典 —— 如果通過 HTTP POST 方法發送一個表單，但是表單中沒有任何的數據，QueryDict 對象依然會被創建。
   因此，不應該使用 if request.POST  來檢查使用的是否是POST 方法；應該使用 if request.method == "POST" 
　　另外：如果使用 POST 上傳文件的話，文件信息將包含在 FILES 屬性中。
'''

Request.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 鍵。
'''

2.3 render

　　結合一個給定的模板和一個給定的上下文字典，並返回一個渲染後的 HttpResponse 對象。

render(request, template_name,{}）

template_name:模板名稱

{}:可選，對html文件進行渲染。具體見Django之templetes

return render(request,'dep_change.html',{'dep_init_name':dep_init_name})

return render(request,'dep_change.html',locals())      #不需一個一個傳值

2.4 redirect

重定向。參數為一個url地址。

Django之views