Django 提供了 django.utils.deprecation.MiddlewareMixin
来方便创建同时兼容 MIDDLEWARE
和旧的 MIDDLEWARE_CLASSES
的中间件类,并支持同步和异步请求。Django 所包含的所有中间件类都兼容这两种配置。
mixin
提供了一个 __init__()
方法,它需要一个 get_response
参数,并将其存储在 self.get_response
中。
__call__()
方法:
self.process_request(request)
(如果被定义过)。self.get_response(request)
来从后续的中间件和视图得到响应。self.process_response(request, response)
(如果被定义过)。如果和 MIDDLEWARE_CLASSES
一起使用,__call__()
方法将永远不会被使用;Django 会直接调用 process_request()
和 process_response()
。
在大多数情况下,从这个 Mixin
中继承就足以使一个旧式中间件与新系统兼容,并具有足够的向后兼容性。新的短路语义对现有中间件无害甚至有益。在少数情况下,中间件类可能需要一些改变来适应新的语义。
MIDDLEWARE
和 MIDDLEWARE_CLASSES
在使用上有些行为差异:
MIDDLEWARE_CLASSES
下,每个中间件将始终调用它的 process_response
方法,即使早期的中间件通过从其 process_response
方法返回响应而短路。MIDDLEWARE
下,中间件行为更像洋葱:响应在输出时经过的层与在输入时看到请求的层相同。如果一个中间件短路,只有那个中间件和之前的中间件可以看到响应。MIDDLEWARE_CLASSES
下,process_exception
应用于中间件 process_request
方法引发的异常。在 MIDDLEWARE
下,process_exception
只应用于视图引发的异常(或者从 TemplateResponse
的 render
方法引发的异常)。中间件引发的异常被转换为合适的 HTTP 响应,然后传递到下一个中间件。MIDDLEWARE_CLASSES
下,如果 process_response
方法引发了异常,所有更早之前的中间件的 process_response
方法会被跳过,并一直返回 500 Internal Server Error
的 HTTP 响应(即使引发的异常是例如 Http404 )。在 MIDDLEWARE
,一个中间件引发的异常将立刻被转换为合适的 HTTP 响应,然后下一个中间件将看到响应。中间件不会因为中间件引发异常而被跳过。你可以通过设置 SESSION_EXPIRE_AT_BROWSER_CLOSE 来控制会话框架是使用 browser-length sessions还是persistent sessions。...
Model._base_manager用于访问关联对象的管理器默认情况下,Django 访问关联对象(即 choice.question)时使用 Model._base...
模型当中最重要的属性是 Manager。它是 Django 模型和数据库查询操作之间的接口,并且它被用作从数据库当中 获取实例,...
自动测试化是什么?测试代码,是用来检查你的代码能否正常运行的程序。测试在不同的层次中都存在。有些测试只关注某个很小的细节...
如果你只是想测试异步视图的输出,标准测试客户端将在自己的异步循环中运行它们,而不需要你做任何额外的工作。但是,如果你想为...