Django之路由层
每一个URL
都会对应一个视图函数,当一个用户请求访问Django
站点的一个页面时,然后就由Django
路由系统(URL配置文件
)去决定要执行哪个视图函数使用的算法。这个路由系统我们也称之为url控制器
,一般是项目目录和应用目录里的urls.py
文件。
路由配置是所有整个Django
的入口,我们想要访问什么,想要去什么地方,都取决路由,所以我们需要充分理解路由配置的用法。
一般情况下,一个URL
,我们是这样写的:
1 | urlpatterns = [ |
下面是一个简单的路由配置例子:
1 | from django.urls import path |
注意:
- 要捕获一段
url
中的值,需要使用尖括号,而不是之前的圆括号; - 可以转换捕获到的值为指定类型,比如例子中的
<int:year>
。默认情况下,捕获到的结果保存为字符串类型,不包含**/
**这个特殊字符; - 规则的前面不需要添加**
/
,因为默认情况下,每个url
都带一个最前面的/
**。比如:articles
, 不能写成/articles
。
匹配例子:
1、/articles/2005/03/
将匹配第三条,并调用views.month_archive(request, year=2005, month=3);
2、/articles/2003/
匹配第一条,并调用views.special_case_2003(request);
3、/articles/2003
将一条都匹配不上,因为它最后少了一个斜杠,而列表中的所有模式中都以斜杠结尾;
4、/articles/2003/03/building-a-django-site/
将匹配最后一个,并调用views.article_detail(request, year=2003, month=3, slug="building-a-django-site"
一、path
转换器
Django
默认情况下内置下面的路径转换器:
1、str
:匹配任何非空字符串,但不含斜杠/,如果你没有专门指定转换器,那么这个是默认使用的;
2、int
:匹配0和正整数,返回一个int类型
3、slug
:可理解为注释、后缀、附属等概念,是url
拖在最后的一部分解释性字符。该转换器匹配任何ASCII字符以及连接符和下划线,比如’ building-your-1st-django-site‘
;
4、uuid
:匹配一个uuid
格式的对象。为了防止冲突,规定必须使用破折号,所有字母必须小写,例如’075194d3-6885-417e-a8a8-6c931e272f00
‘ 。返回一个UUID
对象;
5、path
:匹配任何非空字符串,重点是可以包含路径分隔符’/
‘。这个转换器可以帮助你匹配整个url
而不是一段一段的url
字符串。
二、注册自定义路径转换器
对于更复杂的匹配需求,您可以定义自己的路径转换器。自定义,就是单独写一个类,它包含下面的内容:
1、类属性regex
:一个字符串形式的正则表达式属性;
2、to_python(self, value)
方法:一个用来将匹配到的字符串转换为你想要的那个数据类型,并传递给视图函数。如果不能转换给定的值,则会引发ValueError
。
3、to_url(self, value)
方法:将Python
数据类型转换为一段url
的方法,上面方法的反向操作。
例如:
1 | class FourDigitYearConverter: |
在路由
中注册自定义转换器类,并使用它:
1 | from django.urls import path, register_converter |
三、使用正则表达式
如果路径和转换器语法不足以定义URL模式,也可以使用正则表达式。这时我们就需要使用re_path()
而不是path()
。
在Python
正则表达式中,命名正则表达式组的语法是 (?P<name>pattern)
,其中name
是组的名称,pattern
是需要匹配的规则。
前面的路由示例,如果使用正则表达式重写,是这样子的:
1 | from django.urls import path, re_path |
re_path
与path()
不同的主要在于两点:
1、year
中匹配不到10000
等非四位数字,这是正则表达式决定的
2、传递给视图的所有参数都是字符串类型。而不像path()
方法中可以指定转换成某种类型。
四、指定视图参数的默认值
有一个方便的小技巧是指定视图参数的默认值。 下面是一个路由配置和视图的示例:
1 | # 路由 |
在上面的例子中,两个URL模式指向同一个视图views.page
—— 但是第一个模式不会从URL
中捕获任何值。如果第一个模式匹配,page()
函数将使用num
参数的默认值”1”。如果第二个模式匹配,page()
将使用正则表达式捕获的num
值。
五、路由匹配请求URL
中的哪些部分
请求的URL
被看做是一个普通的Python
字符串,路由在其上查找并匹配。进行匹配时将不包括GET
或POST
请求方式的参数以及域名。
例如,在https://www.example.com/myapp/的请求中,路由将查找`myapp/`。
在https://www.example.com/myapp/?page=3的请求中,路由也将查找`myapp/`。
路由不检查使用何种HTTP请求方法,所有请求方法POST、GET、HEAD等都将路由到同一个URL的同一个视图。在视图中,才根据具体请求方法的不同,进行不同的处理。
六、错误页面处理
当Django
找不到与请求匹配的URL
时,或者当抛出一个异常时,将调用一个错误处理视图。错误视图包括400、403、404和500,分别表示请求错误、拒绝服务、页面不存在和服务器错误。它们分别位于:
1 | - handler400 —— django.conf.urls.handler400。 |
这些值可以在根路由中设置。在其它app
中的二级路由中设置这些变量无效。
Django
有内置的HTML
模版,用于返回错误页面给用户,但是这些403,404页面实在丑陋,通常我们都自定义错误页面。
首先,在根路由中额外增加下面的条目:
1 | # urls.py |
然后在,views.py
文件中增加四个处理视图:
1 | def page_not_found(request, exception): |
再根据自己的需求,创建404.html
、400.html
等四个页面文件,就可以了。
注意,运行如果报错视图函数参数需要添加
exception
参数,另外settings.py
中debug
要设为false
才能看到效果。
七、urls
分层模块化(路由分发)
通常,我们会在每个app
里,各自创建一个urls.py
路由模块,然后从根路由出发,将app
所属的url
请求,全部转发到相应的urls.py
模块中。
例如,下面是Django
网站本身的路由节选。 它包含许多其它路由:
1 | from django.urls import include, path |
路由转发使用的是include()
方法,需要提前导入,它的参数是转发目的地路径的字符串,路径以圆点分割。
注意,这个例子中的正则表达式没有包含$(字符串结束匹配符),但是包含一个末尾的斜杠。 每当Django
遇到include()
(来自django.conf.urls.include()
)时,它会去掉URL
中匹配的部分并将剩下的字符串发送给include
的路由做进一步处理,也就是转发到二级路由去。
另外一种转发其它URL
模式的方式是使用一个url()
实例的列表。 例如,下面的路由:
1 | from django.urls import include, path |
在这个例子中, /credit/reports/
URL
将被 credit.views.report()
这个Django
视图处理。
上面这种方法可以用来去除路由 中的冗余,其中某个模式前缀被重复使用。例如,下面这个例子:
1 | from django.urls import path |
我们可以改进它,通过只声明共同的路径前缀一次并将后面的部分分组转发:
1 | from django.urls import include, path |
八、捕获参数
被转发的路由会收到来自父路由捕获的所有参数,看下面的例子:
1 | # In settings/urls/main.py |
在上面的例子中,捕获的”username
“变量将被传递给include()
指向的路由,再进一步传递给对应的视图。
九、嵌套参数
正则表达式允许嵌套参数,Django
将解析它们并传递给视图。当反查时,Django
将尝试填满所有外围捕获的参数,并忽略嵌套捕获的参数。 考虑下面的URL
模式,它带有一个可选的page
参数:
1 | from django.urls import re_path |
两个模式都使用嵌套的参数,其解析方式是:例如blog/page-2/
将匹配page-2/
并带有两个位置参数blog_articles
和2。第二个comments
的模式将匹配page_number
并带有一个值为2的关键字参数comments/page-2/
。这个例子中外围参数是一个不捕获的参数(?:…)。
blog_articles
视图需要最外层捕获的参数来反查,在这个例子中是comments
或者没有参数,而page-2/
可以不带参数或者用一个page_number
值来反查。
十、向视图传递额外的参数
路由s具有一个钩子(hook
),允许你传递一个Python
字典作为额外的关键字参数给视图函数。
像这样:
1 | from django.urls import path |
在上面的例子中,对于/blog/2005/
请求,Django
将调用views.year_archive(request, year='2005', foo='bar')
。理论上,你可以在这个字典里传递任何你想要的传递的东西。但是要注意,URL模式捕获的命名关键字参数和在字典中传递的额外参数有可能具有相同的名称,这会发生冲突,要避免。
十一、传递额外的参数给include()
类似上面,也可以传递额外的参数给include()
。参数会传递给include
指向的路由中的每一行。
例如,下面两种路由配置方式在功能上完全相同:
配置一:
1 | # main.py |
配置二:
1 | # main.py |
注意,只有当你确定被include
的路由中的每个视图都接收你传递给它们的额外的参数时才有意义,否则其中一个以上视图不接收该参数都将导致错误异常。
十二、url
的反向解析
在实际的Django
项目中,经常需要获取某条URL
,为生成的内容配置URL
链接。
比如,我要在页面上展示一列文章列表,每个条目都是个超级链接,点击就进入该文章的详细页面。
现在我们的路由是这么配置的:^post/(?P\d+)
。
在前端中,这就需要为HTML的``标签的href属性提供一个诸如http://www.xxx.com/post/3
的值。其中的域名部分,Django会帮你自动添加无须关心,我们关注的是post/3
。
此时,一定不能硬编码URL为post/3
,那样费时、不可伸缩,而且容易出错。试想,如果哪天,因为某种原因,需要将路由中的正则改成^entry/(?P\d+)
,为了让链接正常工作,必须修改对应的herf
属性值,于是你去项目里将所有的post/3
都改成entry/3
吗?显然这是不行的!
我们需要一种安全、可靠、自适应的机制,当修改路由中的代码后,无需在项目源码中大范围搜索、替换失效的硬编码URL
。
为了解决这个问题,Django
提供了一种解决方案,只需在URL
中提供一个name
参数,并赋值一个你自定义的、好记的、直观的字符串。
通过这个name
参数,可以反向解析URL
、反向URL
匹配、反向URL
查询或者简单的URL
反查。
在需要解析URL
的地方,对于不同层级,Django
提供了不同的工具用于URL
反查:
- 在模板语言中:使用
url
模板标签。(也就是写前端网页时) - 在
Python
代码中:使用reverse()
函数。(也就是写视图函数等情况时) - 在更高层的与处理
Django
模型实例相关的代码中:使用get_absolute_url()
方法。(也就是在模型model
中)
示例:
1 | from django.urls import path |
某一年nnnn
对应的归档的URL
是/articles/nnnn/
。
可以在模板的代码中使用下面的方法获得它们:
1 | <a href="{% url 'news-year-archive' 2012 %}">2012 Archive</a> |
在Python
代码中,这样使用:
1 | from django.http import HttpResponseRedirect |
其中,起到核心作用的是我们通过name='news-year-archive'
为那条url
起了一个可以被引用的名称。
URL
名称name
使用的字符串可以包含任何你喜欢的字符,但是过度的放纵有可能带来重名的冲突,比如两个不同的app
,在各自的路由中为某一条url
取了相同的name
,这就会带来麻烦。为了解决这个问题,又引出了下面命名的URL模式。
十三、命名的URL
模式(URL
别名)
URL
别名可以保证反查到唯一的URL
,即使不同的app
使用相同的URL
名称。
第三方应用始终使用带命名空间的URL
是一个很好的做法。
类似地,它还允许你在一个应用有多个实例部署的情况下反查URL
。 换句话讲,因为一个应用的多个实例共享相同的命名URL
,命名空间提供了一种区分这些命名URL
的方法。
实现命名空间的做法很简单,在路由文件中添加app_name = 'wechat'
和namespace='wechat'
这种类似的定义。
范例:
以两个实例为例子:wechat
和weibo
。
假设我们已经在创建和显示投票时考虑了实例命名空间的问题,代码如下:
1 | # urls.py |
在视图中方向生成连接
1 | # wechat/views.py |
和在模板中:
1 | <h2>当前连接:{% url 'wechat:index' %}</h2> |
十四、URL命名空间和include的路由
可以通过两种方式指定include的路由的应用名称空间。
第一种
在include的路由模块中设置与urlpatterns属性相同级别的app_name
属性。必须将实际模块或模块的字符串引用传递到include(),而不是urlpatterns本身的列表。
1 | # polls/urls.py |
此时,polls.urls中定义的URL将具有应用名称空间polls。
第二种
include一个包含嵌套命名空间数据的对象。如果你include()一个url()实例的列表,那么该对象中包含的URL将添加到全局命名空间。 但是,你也可以include()一个2元组,其中包含:
1 | (<list of path()/re_path() instances>, <application namespace>) |
例如:
1 | rom django.urls import include, path |
这将include指定的URL模式到给定的app命名空间。
可以使用include()的namespace参数指定app实例命名空间。如果未指定,则app实例命名空间默认为路由的app命名空间。
注:之前不记得有过路由的文章,其他参考可进入:Django路由系统