在上篇文章中我们我们已经已经知道request在Django中的过程,如果没有看过上篇文章 Django系列:请求的生命周期(1)的,可以先看一下,已对你对本文有更好的理解。
本文着重讲解当一个request来到Django后, 是如何进行视图函数或视图类的匹配的,以及如何正确调用请求方法,下图就是当request进来时所要进行请求解析的入口源码:
那么 self.resolve_request(request) 这句代码的背后究竟干了什么了呢?
我们在开发新应用的过程中,都需要用到 urls.py 这个路由文件,那么我们先了解一下:include,path, re_path 三个函数都是干什么的:
注意:from django.conf.urls import url 中url函数将会被弃用,所以我们不讨论该函数
from django.urls import re_path, path, include
(1):def include(arg, namespace=None)
参数:
arg:tuple | module,本质上是一个包含 urlpatterns 变量的 urls.py 文件模块
(a): 当为元组时, 必须是二元素元素,args=(urlconf_module, app_name),urlconf_module是定向应用或根项目 urls.py 文件的路径,app_name可以是应用名称;
(b): 当为模块变量是,其模块是包含有 urlpatterns 的变量
namespace:命名空间,当namespace存在时,app_name必须存在
返回值:(urlconf_module, app_name, namespace) 三元组;urlconf_module 是一个模块变量
(2):path 和 re_path 都是路由系统,只不过 re_path 的路径包含正则表达式而已
(3):当整个Django项目启动后,会根据ROOT_URLCONF的配置,形成一个链式的路由系统,请求匹配最终需要该类:django.urls.resolvers:URLResolver 解析,经调试候在代码的样子大致如下:
(4):好了, 现在我们知道请求解析匹配的类,那么我们具体看看是如何匹配的,在(1)处时,已经知道请求的入口了,就是这句代码:
callback, callback_args, callback_kwargs =self.resolve_request(request)
resolve_request 方法的可信在这2句代码,请看下图:
resolver = get_resolver():resolver 其实就是(3)提到的URL解析类:django.urls.resolvers:URLResolver, resolver = <URLResolver 'config.urls' (None:None) '^/'>, 对于resolver 的 urlpatterns 属性,它又是链式的。
resolver.resolve(request.path_info),它返回的是一个 django.urls.resolvers:ResolverMatch类,其实ResolverMatch是一个元组,因为它实现了 __getitem__ 魔法函数, 返回值就是 :
callback: 视图类, CBV.as_view() 函数
callback_args:请求的非关键字参数
callback_kwargs :请求的关键字参数
至此,我们知道请求最终解析后的样子,那么他最终执行视图函数返回Response实例:
response = wrapped_callback(request, *callback_args, **callback_kwargs)
(5):当试图函数执行后,经过 模板中间件、response渲染、异常中间件后,response 再次执行中间件的process_response方法,注意是逆序执行,最终到达第一个中间件后返回wsgi或uwsgi服务器,然后返回给浏览器。
网友评论