Django之URL反向解析

在反向解析和命名空間之前我們先來說說urls硬編碼，用django 開發應用的時候，可以完全是在urls.py 中硬編碼配置位址,在views.py中httpresponseredirect()也是硬編碼轉向位址，當然在template 中也是一樣了，這樣帶來乙個問題，如果在urls.py 中修改了某個頁面的位址（也就是說更改路由系統中對應的路由分發），那麼所有的地方(views.py和template中)都要修改。問題出在硬編碼，緊耦合使得在大量的模板中修改 urls 成為富有挑戰性的專案。來看下面的模板檔案index.html中，我們到的鏈結硬編碼成這樣子：

url硬編碼

如果使用軟編碼之後，無論怎麼更改路由系統中的路由分發，只有對應的namespace與name屬性值不變，就不必修改在views.py和template中的url，也就是說

url軟編碼

在templates中更改為軟編碼之後，其實在templates，index.html檔案生成的時候，仍然是

url軟編碼

在使用django 專案時，乙個常見的需求是獲得url 的最終形式，以用於嵌入到生成的內容中（檢視中和顯示給使用者的url等）或者用於處理伺服器端的導航（重定向等）。人們強烈希望不要硬編碼這些url（費力、不可擴充套件且容易產生錯誤）或者設計一種與urlconf 毫不相關的專門的url 生成機制，因為這樣容易導致一定程度上產生過期的url。

獲取乙個url 最開始想到的資訊是處理它檢視的標識（例如名字），查詢正確的url 的其它必要的資訊有檢視引數的型別（位置引數、關鍵字引數）和值。django 提供乙個辦法是讓url 對映是url 設計唯一的地方。你填充你的urlconf，然後可以雙向使用它：1、根據使用者/瀏覽器發起的url 請求，它呼叫正確的django 檢視，並從url 中提取它的引數需要的值。2、根據django 檢視的標識和將要傳遞給它的引數的值，獲取與之關聯的url。

第一種方式是我們常說的根據位址定位url。

第二種方式叫做反向解析url、反向url 匹配、反向url 查詢或者簡單的url 反查。

在需要url 的地方，對於不同層級，django 提供不同的工具用於url 反查：1、在模板中：使用url 模板標籤。2、在python **中：使用 django.core.urlresolvers.reverse()函式。3、在更高層的與處理django 模型例項相關的**中：使用 get_absolute_url() 方法。

url 命名空間允許你反查到唯一的命名url 模式，即使不同的應用使用相同的url 名稱。第三方應用始終使用帶命名空間的url 是乙個很好的實踐。類似地，它還允許你在乙個應用有多個例項部署的情況下反查url。換句話講，因為乙個應用的多個例項共享相同的命名url，命名空間將提供一種區分這些命名url 的方法。

乙個url 命名空間有兩個部分，它們都是字串：

<1>、應用命名空間:

它表示正在部署的應用的名稱。乙個應用的每個例項具有相同的應用命名空間。例如，可以預見django 的管理站點的應用命名空間是' admin '。

<2>、例項命名空間:

它表示應用的乙個特定的例項。例項的命名空間在你的全部專案中應該是唯一的。但是，乙個例項的命名空間可以和應用的命名空間相同。它用於表示乙個應用的預設例項。例如，django 管理站點例項具有乙個預設的例項命名空間'admin'。 url的命名空間使用':' 操作符指定。例如，管理站點應用的主頁使用' admin:index '。它表示' admin ' 的乙個命名空間和' index ' 的乙個命名url.

＃ include函式的api

一般來說，同一應用下的不同例項應該具有相同的應用命名空間，但是，這並不意味著不同應用可以使用相同的例項命名空間，因為例項命名空間在你所有專案中都是唯一的。
問題：另外在新增命名空間 namespace時可能會出現以下這個問題：
==解決方案為：==

from django.conf.urls import url
from . import views
# users為當前應用的名稱
urlpatterns = [
url('^$', views.index),
url('^(\d+)/$', views.detail),
]

daily_fresh_demo　
|----daily_fresh_demo
|----__init__.py
|----settings.py
|----urls.py
|----wsgi.py
|----df_cart #對商品購物車管理
|---- migrations # 遷移檔案目錄
|---- admin.py
|---- models.py
|---- test.py
|---- urls.py
|---- views.py
|---- __init__.py
|----df_goods　　#商品以及後台管理
...|----df_user #使用者管理
...|----df_order #訂單管理 
...|----templates
|index.html

daily_fresh_demo/daily_fresh_demo/urls.py
from django.contrib import admin
from django.urls import path
from django.conf.urls import url, include
urlpatterns = [
path('admin/', admin.site.urls),
url(r'^goods/', include('df_goods.urls', namespace='df_goods')), # 新增例項命名空間
url(r'^user/', include('df_user.urls', namespace='df_user')),
url(r'^cart/', include('df_cart.urls', namespace='df_cart')),
url(r'^order/', include('df_order.urls', namespace='df_order')),
]

daily_fresh_demo/df_goods/urls.py
from django.conf.urls import url
from . import views
urlpatterns = [
url('^index/$', views.index, name="index"),
]

df_goods中的路由，新增應用命名空間。並在url函式中新增name屬性。

3、檢視函式

daily_fresh_demo/df_goods/views.py
from django.shortcuts import render, reverse
def index(request):
print(reverse("df_goods:index")) # 利用reverse函式反向解析url
# 列印結果為/goods/index/
return render(request, 'index.html')

4、靜態檔案 index.html

*********x daily_fresh_demo/templates/index.html硬鏈結

軟鏈結

5、結果

靜態檔案中index.html的url解析結果如下

硬鏈結軟鏈結 # 軟編碼通過解析後得到的結果與硬編碼一致

總結：這樣一來通過命名空間，無論在templates檔案中有多龐大的url位址對映，只要使用url軟編碼，在更改路由系統的時候，都能自動生成。而如果使用硬鏈結硬編碼，就只能在views.py和靜態檔案中逐個修改url位址，不僅耗費時間，更容易產生錯誤。

Django之URL反向解析

Django之url反向解析

django之url反向解析

django的url反向解析

Django之URL反向解析

Django之url反向解析

django之url反向解析

django的url反向解析

相關推薦