ジャンゴジャンゴ---ミドルウェア
ディアンは、ミドルウェアを導入しました
ミドルウェアとは何ですか
官方的说法：中间件是一个用来处理Django的请求和响应的框架级别的钩子。它是一个轻量、低级别的插件系统，用于在全局范围内改变Django的输入和输出。每个中间件组件都负责做一些特定的功能。
但是由于其影响的是全局，所以需要谨慎使用，使用不当会影响性能。
#中间件是:在视图函数执行之前和执行之后都可以做一些额外的操作，它本质上就是一个自定义类，类中定义了几个方法，Django框架会在处理请求的特定的时间去执行这些方法。
# 打开Django项目的Settings.py文件，看到下图的MIDDLEWARE配置项。
MIDDLEWARE = [
'django.middleware.security.SecurityMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware', # 全局session
'django.middleware.common.CommonMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'django.middleware.clickjacking.XFrameOptionsMiddleware',
]
# MIDDLEWARE配置项是一个列表，列表中是一个个字符串，这些字符串其实是一个个类，也就是一个个中间件。二ディアンカスタムミドルウェア
ミドルウェアは）、すなわち:(主なものは、process一とprocess_responseで、5つのメソッドを定義することができます
- process一（自己、リクエスト）
- process_view（自己、リクエスト、view_func、view_argsと、view_kwargs）
- process_template_response（自己、リクエスト、レスポンス）
- process_exception（自己、リクエスト、例外）
- process_response（自己、リクエスト、レスポンス）
上記方法のリターン値なしHttpResponseオブジェクトとすることがないか、なし、その後、Djangoに定義されたルールに従って継続するバック進行されていない場合はよいのHttpResponseオブジェクト場合、オブジェクトはユーザーに直接戻されます。
カスタムミドルウェアの例
# 实现中间件的类
from django.utils.deprecation import MiddlewareMixin
class MD1(MiddlewareMixin):
def process_request(self, request):
print("MD1里面的 process_request")
def process_response(self, request, response):
print("MD1里面的 process_response")
return response # 必须返回response
# settings配置注册中间件
'app01.middleware.MD1',process一（自己、リクエスト）：
def process_request(self, request):
'''
正常流程: 返回值必须为none ,按照 settings配置的中间件的顺序从上到下执行,
# 若返回 HTTPResponse对象,则直接通过当前中间件的 process_response返回.
# 在路由(urls.py)和函数(view)之前进行处理
:param request:
:return:
'''
print('In M1 process_request ')
# 执行时间：
在执行视图函数之前,也在路由匹配之前
# 参数：
request： 请求对象 和视图是同一个
# 执行的顺序：
按照中间件的注册顺序 顺序执行
# 返回值：
None ： 正常流程
HttpResponse：当前中间件之后的中间件的process_request、路由匹配、视图函数都不执行，直接执行当前中间的process_response的方法，倒序执行之前的process_response的方法，最终返回给浏览器process_response（自己、要求、応答）：
def process_response(self, request, response):
'''
正常流程: 必须返回response, 按照settings配置中的中间件顺序,倒序返回.
# 可以自己指定返回的HttpResponse对象
# request 在一次请求中 ,始终是同一个
# 在路由(urls.py)和函数(view)之后进行处理
:param request:
:param response:
:return:
'''
print('out M1 process_response ')
return response # 必须返回
# 执行时间：
在执行视图函数之后
# 参数：
request： 请求对象 和视图是同一个
response: 返回的response对象
# 执行的顺序：
按照中间件的注册顺序 倒序执行
# 返回值：
HttpResponse：必须返回response对象process_view（自己、リクエスト、view_func、view_argsと、view_kwargs）：
def process_view(self, reques, view_func, view_args, view_kwargs):
'''
# 正常流程: 返回none ,按照 settings配置的中间件的顺序从上到下执行,
# 可以修改函数的参数,或者修改函数返回的HttpResponse
# M1 process_view 处理完, 交给 M2 process_view处理. 处理完毕后执行 真正要处理的视图函数(view_func函数)
# 在 路由之后,函数之前进行处理
:param reques:
:param view_func:
:param view_args:
:param view_kwargs:
:return:
'''
print('in M1 process_view ')
print(view_func, view_args, view_kwargs)
# 执行时间：
在执行视图函数之前，在路由匹配之后
# 参数：
request： 请求对象 和视图是同一个
view_func： 视图函数
view_args： 传递给视图函数的位置参数 分组的参数
view_kwargs： 传递给视图函数的关键字参数 命名分组的参数
# 执行的顺序：
按照中间件的注册顺序 顺序执行
# 返回值：
None : 正常流程
HttpResponse：当前中间件之后的中间件的process_view、视图函数都不执行，直接执行最后一个中间的process_response的方法，倒序执行之前的process_response的方法，最终返回给浏览器process_exception（自己、リクエスト、例外）：
def process_exception(self, request, execption):
'''
# 使用process_exception 方法 , 条件必须是 出现异常错误
# 执行顺序: 按照settings设置中间件的顺序 ,倒序执行.
如果 最后一个中间件的 process_exception 不能处理,交给 上一个中间件的process_exception处理
如果 都不能处理这个异常,则交给Django默认的配置处理. 最后有Django生成一个HttpResponse对象
# 由settings配置的最后一个中间件 process_response方法 逐层返回.
:param request:
:param execption:
:return:
'''
print('in M1 process_exception')
print(execption) # 打印异常信息
# 执行时间（触发条件）：
视图层面有异常才执行
# 参数：
request： 请求对象 和视图是同一个
exception： 错误对象
# 执行的顺序：
按照中间件的注册顺序 倒序执行
# 返回值：
None : 交给下一个中间件处理异常，所有的中间件都没有处理，交给django处理
HttpResponse：当前中间件之前的中间件的process_exception不执行，直接执行最后一个中间的process_response的方法，倒序执行之前的process_response的方法，最终返回给浏览器process_template_response（自己、要求、応答）：
def process_template_response(self, request, response):
'''
# 执行顺序: 按照settings设置中间件的顺序 ,倒序执行.
# response得到是一个TemplateResponse对象
# 可以修改属性和值
# 存在视图函数之后, 按照倒序执行完毕后,才进行最终的渲染.
然后交由 settings最后中间件 执行 process_response逐层返回
:param request:
:param response:
:return:
'''
print(response, type(response), '这是TemplateResponse对象')
# <TemplateResponse status_code=200, "text/html; charset=utf-8">
# <class 'django.template.response.TemplateResponse'> 这是TemplateResponse对象
# 可以通过 response 获取模板文件的名字, 或者修改传递的参数
# print(response.__dict__) # 查看都有什么属性
print(response.template_name) # 获得模版的名字
print(response.context_data) # 获得传递需要渲染的参数
# 修改 模版文件
response.template_name = 'logout.html'
print('in M1 process_template_response ')
return response # 必须返回response
# 执行时间（触发条件）：
视图返回的response 是一个template_response对象
# 参数：
request： 请求对象 和视图是同一个
response： 响应对象
# 执行的顺序：
按照中间件的注册顺序 倒序执行
# 返回值：
HttpResponse：必须返回水とミドルウェアプロセスの実装
# 请求到达中间件之后，先按照正序执行每个注册中间件的process_reques方法，process_request方法返回的值是None，就依次执行，如果返回的值是HttpResponse对象，不再执行后面的process_request方法，而是执行当前对应中间件的process_response方法，将HttpResponse对象返回给浏览器。也就是说：如果MIDDLEWARE中注册了6个中间件，执行过程中，第3个中间件返回了一个HttpResponse对象，那么第4,5,6中间件的process_request和process_response方法都不执行，顺序执行3,2,1中间件的process_response方法。
# process_request方法都执行完后，匹配路由，找到要执行的视图函数，先不执行视图函数，先执行中间件中的process_view方法，process_view方法返回None，继续按顺序执行，所有process_view方法执行完后执行视图函数。假如中间件3 的process_view方法返回了HttpResponse对象，则4,5,6的process_view以及视图函数都不执行，直接从最后一个中间件，也就是中间件6的process_response方法开始倒序执行。
# process_template_response和process_exception两个方法的触发是有条件的，执行顺序也是倒序。总结所有的执行流程如下
附属書：Djangoのフローチャート要求
