Django的路由理解

最近在写Django的项目，URL路由这边分发能够理解，但是稍微复杂的正则表达式一直有很大的问题，总结一下。

一、Django的请求处理

（1）首先，最开始的URL是在项目的主目录下面，通常，这是ROOT_URLCONF设置的值，但是如果传入的HttpRequest对象具有urlconf属性（由中间件设置），则其值将被用于代替ROOT_URLCONF设置。通俗的讲，就是你可以自定义项目入口url。

（2）依次匹配每个URL模式，在与请求的URL相匹配的第一个模式停下来。也就是说，url匹配是从上往下的短路操作，所以url在列表中的顺序非常关键。

（3）导入并调用匹配行中给定的视图，在views文件里面。该视图是一个简单的Python函数（被称为视图函数）,或基于类的视图。

（4）视图将获得如下参数: 一个HttpRequest 实例。 如果匹配的正则表达式返回了没有命名的组，那么正则表达式匹配的内容将作为位置参数提供给视图。 关键字参数由正则表达式匹配的命名组组成，但是可以被django.conf.urls.url()的可选参数kwargs覆盖。

（5）如果没有匹配到正则表达式，或者过程中抛出异常，将调用一个适当的错误处理视图。

二、 转换器

（1）path转换器

在django2.0 以上的版本中，默认使用的是path转换器，我们首先以此举例：

from django.urls import path

from . import views

urlpatterns = [
    path('articles/2003/', views.special_case_2003),
    path('articles/<int:year>/', views.year_archive),
    path('articles/<int:year>/<int:month>/', views.month_archive),
    path('articles/<int:year>/<int:month>/<slug:slug>/', views.article_detail),
]

1. 要捕获一段url中的值，需要使用尖括号，而不是之前的圆括号；可以转换捕获到的值为指定类型，比如例子中的int。默认情况下，捕获到的结果保存为字符串类型，不包含/这个特殊字符；匹配模式的最开头不需要添加/，因为默认情况下，每个url都带一个最前面的/，既然大家都有的部分，就不用浪费时间特别写一个了。
2. 默认情况下，Django内置下面的路径转换器： str：匹配任何非空字符串，但不含斜杠/，如果你没有专门指定转换器，那么这个是默认使用的； int：匹配0和正整数，返回一个int类型 slug：可理解为注释、后缀、附属等概念，是url拖在最后的一部分解释性字符。该转换器匹配任何ASCII字符以及连接符和下划线，比如’ building-your-1st-django-site‘； uuid：匹配一个uuid格式的对象。为了防止冲突，规定必须使用破折号，所有字母必须小写，例如’075194d3-6885-417e-a8a8-6c931e272f00‘ 。返回一个UUID对象； path：匹配任何非空字符串，重点是可以包含路径分隔符’/‘。这个转换器可以帮助你匹配整个url而不是一段一段的url字符串。

（2）re_path转换器（老版的url）

Django2.0的url虽然改‘配置’了，但它依然向老版本兼容。而这个兼容的办法，就是用re_path()方法代替path()方法。re_path()方法在骨子里，就是以前的url()方法，只不过导入的位置变了。

from django.urls import path, re_path

from . import views

urlpatterns = [
    path('articles/2003/', views.special_case_2003),
    re_path(r'^articles/(?P<year>[0-9]{4})/$', views.year_archive),
    re_path(r'^articles/(?P<year>[0-9]{4})/(?P<month>[0-9]{2})/$', views.month_archive),
    re_path(r'^articles/(?P<year>[0-9]{4})/(?P<month>[0-9]{2})/(?P<slug>[\w-]+)/$', views.article_detail),
]

与path()方法不同的在于两点：

year中匹配不到10000等非四位数字，这是正则表达式决定的

传递给视图的所有参数都是字符串类型。而不像path()方法中可以指定转换成某种类型。在视图中接收参数时一定要小心。

 

（3）有名分组

上面的示例使用简单的、没有命名的正则表达式组（通过圆括号）来捕获URL 中的值并以位置 参数传递给视图。在更高级的用法中，可以使用命名的正则表达式组来捕获URL 中的值并以关键字 参数传递给视图。 在Python 正则表达式中，命名正则表达式组的语法是(?Ppattern)，其中name 是组的名称，pattern 是要匹配的模式。 下面是以上URLconf 使用命名组的重写：

from django.urls import path,re_path

from app01 import views

urlpatterns = [
re_path(r'^articles/2003/$', views.special_case_2003),
re_path(r'^articles/(?P<year>[0-9]{4})/$', views.year_archive),
re_path(r'^articles/(?P<year>[0-9]{4})/(?P<month>[0-9]{2})/$', views.month_archive),
re_path(r'^articles/(?P<year>[0-9]{4})/(?P<month>[0-9]{2})/(?P<day>[0-9]{2})/$', views.article_detail),
]

这个实现与前面的示例完全相同，只有一个细微的差别：捕获的值作为关键字参数而不是位置参数传递给视图函数。例如：

/articles/2005/03/ 请求将调用views.month_archive(request, year='2005', month='03')函数，而不是views.month_archive(request, '2005', '03')。
/articles/2003/03/03/ 请求将调用函数views.article_detail(request, year='2003', month='03', day='03')。

（4）路由分发

我们建立了几个APP，在每个app里，各自创建一个urls.py路由模块，然后从根路由出发，将app所属的url请求，全部转发到相应的urls.py模块中。

例如，从Django网站出发， 它包含许多其它小的APP的URLconf：

from django.conf.urls import include, url

urlpatterns = [
    # ... 忽略 ...
    re_path(r'^community/', include('django_website.aggregator.urls')),
    re_path(r'^contact/', include('django_website.contact.urls')),
    # ... 忽略 ...
]

我们可以改进它，只需要声明共同的路径前缀一次，并将后面的部分分组转发：

from django.conf.urls import include, url
from . import views

urlpatterns = [
    re_path(r'^(?P<page_slug>[\w-]+)-(?P<page_id>\w+)/', include([
        re_path(r'^history/$', views.history),
        re_path(r'^edit/$', views.edit),
        re_path(r'^discuss/$', views.discuss),
        re_path(r'^permissions/$', views.permissions),
    ])),
]

（5）反向解析

在使用Django 项目时，一个常见的需求是获得URL 的最终形式，以用于嵌入到生成的内容中（视图中和显示给用户的URL等）或者用于处理服务器端的导航（重定向等）。人们强烈希望不要硬编码这些URL（费力、不可扩展且容易产生错误）或者设计一种与URLconf 毫不相关的专门的URL 生成机制，因为这样容易导致一定程度上产生过期的URL。 在需要URL 的地方，对于不同层级，Django 提供不同的工具用于URL 反查：

1. 在模板中：使用url 模板标签。
2. 在Python 代码中：使用from django.urls import reverse()函数 urls.py:

from django.conf.urls import url

from . import views

urlpatterns = [
#...
re_path(r'^articles/([0-9]{4})/$', views.year_archive, name='news-year-archive'),
#...
]

（6）名称空间

命名空间（英语：Namespace）是表示标识符的可见范围。一个标识符可在多个命名空间中定义，它在不同命名空间中的含义是互不相干的。这样，在一个新的命名空间中可定义任何标识符，它们不会与任何已有的标识符发生冲突，因为已有的定义都处于其它命名空间中。 由于name没有作用域，Django在反解URL时，会在项目全局顺序搜索，当查找到第一个name指定URL时，立即返回 我们在开发项目时，会经常使用name属性反解出URL，当不小心在不同的app的urls中定义相同的name时，可能会导致URL反解错误，为了避免这种事情发生，引入了命名空间。

project的urls.py:

urlpatterns = [
re_path(r'^admin/', admin.site.urls),
re_path(r'^app01/', include("app01.urls",namespace="app01")),
re_path(r'^app02/', include("app02.urls",namespace="app02")),
]

app01.urls：

urlpatterns = [
re_path(r'^index/', index,name="index"),
]

app02.urls：

urlpatterns = [
re_path(r'^index/', index,name="index"),
]

app01.views：

from django.core.urlresolvers import reverse
def index(request):
return HttpResponse(reverse("app01:index"))

app02.views：

from django.core.urlresolvers import reverse
def index(request):
return HttpResponse(reverse("app02:index"))

我在用这个改url的还有一个正则表达式的问题：

错误：

 re_path(r'^ticket/(?P<ticket_id>[0-9]{2}+)/$',
        TicketDetail.as_view(), name='ticketdetailtable'),

正确：

 re_path(r'^ticket/(?P<ticket_id>\d+)/$',
        TicketDetail.as_view(), name='ticketdetailtable'),

上面介绍的是从urlpattern里获取参数，是django内置实现的，还有一种是从HTTP请求里获取参数：

常见的是GET和POST请求，这里的参数被封装在请求request里。

GET请求的数据在request.GET里
POST的请求放在request.POST里
对于GET请求，一般参数直接出现在url里，如domain/search/?q=haha ，可以用request.GET.get('q')或request,GET['q']获取到q参数。
POST请求的数据不会出现在url里。