标签:inf sock ima 通过 bsp 执行流程 文件 module 自己的
在django的settings.py文件下,有一个变量为MIDDLEWARE,里面放的就是中间件。
MIDDLEWARE = [ ‘django.middleware.security.SecurityMiddleware‘, ‘django.contrib.sessions.middleware.SessionMiddleware‘, ‘django.middleware.common.CommonMiddleware‘, ‘django.middleware.csrf.CsrfViewMiddleware‘, ‘django.contrib.auth.middleware.AuthenticationMiddleware‘, ‘django.contrib.messages.middleware.MessageMiddleware‘, ‘django.middleware.clickjacking.XFrameOptionsMiddleware‘, ]
上面就是Django自带的7个中间件,我们想看中间件长什么样子,只需要复制中间件,用from引入,点进去看就可以了。
比如看第二个中间件:from django.middleware.sessions.middleware import SessionMiddleware,看到的结果如下:
class SessionMiddleware(MiddlewareMixin):
def __init__(self, get_response=None):
self.get_response = get_response
engine = import_module(settings.SESSION_ENGINE)
self.SessionStore = engine.SessionStore
def process_request(self, request):
session_key = request.COOKIES.get(settings.SESSION_COOKIE_NAME)
request.session = self.SessionStore(session_key)
def process_response(self, request, response):
。。。。。。
我把process_response()方法下的东西省略了。但我们可以清楚的看出它就是一个继承于MiddlewareMixin的类。
所谓的中间件,就是存在于socket和视图函数中间的一种过滤器。浏览器客户端通过socket发送请求来,要经过一层层中间件的process_request()方法,在进入视图,视图函数执行完毕后,又要经过一层层中间件的process_response()方法,然后再通过socket发送给浏览器客户端。Django服务器端的socket是由wsgiref模块封装而成的,它还帮我们把原生的数据解析成了request对象,从而在Django服务器端才可以用request对象去拿值。
中间件有四个方法,分别是:
1,process_request(self,request) 2,process_response(self, request, response) 3,process_view(self, request, callback, callback_args, callback_kwargs) 4,process_exception(self, request, exception)
现在我们一个一个的来分析每个方法的运用及效果,四个方法讲完了,中间件就学完了。
上面我们说了,浏览器发送请求过来,会经过一层层的process_request,具体来说,会从最上面的中间件到最下面的中间件。执行完视图函数之后,会从从下往上执行每个中间件的process_response(),之后再发送给浏览器。
通常情况下,process_request()是不会写return的,一旦某个中间件的process_request()写了return,那后面的中间件的process_request()就不会执行了,也不会到视图函数了,直接从自己的process_response()依次往上返回。
通常情况下,process_response()都要写上return response。一旦有一个中间件的process_response()没有写return response,那么数据走到这一个中间件时,数据就会丢失,后面要执行的中间件的process_response()都会没有数据。
上面的第二点的执行流程是基于只有request和response的情况下的,如果加上了process_views()。首先还是先走每个中间件的request,然后走到urls.py文件,但现在不会马上去执行视图,而是先要从上往下走每个中间件的process_views(),走完之后再走视图函数,再走每个中间件的response。
第一步是process_request,第二步是process_views,第三步是执行视图函数,第四步是process_response
通常情况下,process_views 也不要加return Httpresponse(‘fff‘),一旦加上了,从这个中间件以下的中间件的process_views就不会执行,视图函数也不会执行。直接跳到最下面中间件的response开始返回。
第一步是process_request,第二步是走部分的process_views,第三步是process_response
process_views()方法还可以写上回调视图函数,它会把对应的视图函数给执行了,然后返回
def process_view(self,request,callback,callback_args,callback_kwargs): response=callback(request,*callback_args,**callback_kwargs)
#callback就是在经过urls.py时对应的视图函数,现在直接在process_views()直接回调视图函数,并且执行
return response
这种情况下,会在执行这个中间件的process_views,把对应的视图函数也一起执行了,然后就直接到最下面中间件从下往上执行response,返回
第一步是prosee_request,第二步是走部分的process_views,第三步是执行process_views里的回调视图函数,第四步是process_response
上面的执行流程是基于没有process_exception()情况下的,加上process_exception(),在执行完视图函数之后,后从下往上执行中间件的process_exception(),然后在从下往上执行中间件的response,然后返回。process_exception()的作用是捕获视图函数的错误。
第一步是process_request,第二步process_views,第三步执行视图函数,第四步process_exception,第五步是process_response.
标签:inf sock ima 通过 bsp 执行流程 文件 module 自己的
原文地址:https://www.cnblogs.com/12345huangchun/p/10251958.html