WSGIHandler继承自BaseHandler,BaseHandler初始化的时候_request_middleware和其他moddleware变量都设置为None。
在WSGIHandler中,先通过判断_request_middleware为None,执行load_middleware。

在load_middleware里根据在settings.MIDDLEWARE_CLASSES里的配置导入所有middleware,并判断class里边包含的方法,分别插入相应的middleware列表里。现在_request_middleware是一个列表。load_middleware结束

回到WSGIHandler,
set_script_prefix(base.get_script_name(environ)),get_script_name从environ得到SCRIPT_NAME,如果设置settings.FORCE_SCRIPT_NAME,回直接返回settings.FORCE_SCRIPT_NAME,默认为None。django竟然还提供这种碉堡的功能。。。set_script_prefix判断SCRIPT_NAME结尾是否是‘/’不是的话加上,并且在threading local里边保存SCRIPT_NAME。

signals.request_started.send(sender=self.__class__),用来调用绑定到request_started的方法,大体看了一下没看懂。

request = self.request_class(environ),得到request,初始化只是设置了一堆的变量。
response = self.get_response(request),,在get_response里得到urlconf,settings.ROOT_URLCONF就是配置url的入口文件。这里先不看了,以后分析。接着在一个大的try语句里,设置response为None,遍历_request_middleware,只要有response返回就停止。如果执行完response还是none,下边匹配url找到view,然后遍历执行_view_middleware,有response就停止。然后遍历完response还是none执行view。
response = wrapped_callback(request, *callback_args, **callback_kwargs)
如果抛出异常,遍历执行_exception_middleware,返回response不为None就停止,如果最后为None,raise再抛异常。看出exception_middleware只用来在用户写的view里边出现异常的处理。
如果执行完view,还是none,就会抛出The view didn't return an HttpResponse object.的异常。
在这里前边的midddleware,只要有response返回,就不会执行后边的,直接到执行下边了。因为在执行middleware的前边,都先判断response是none才执行。
最后,判断response可调用render,遍历执行_template_response_middleware,最后调用response.render()。这个大的try语句检测执行上边这些操作的404 403等各种异常。
最后遍历执行_response_middleware里的方法,然后调用apply_response_fixes,执行response_fixes里的所有方法修改response。response_fixes在BaseHandler开始定义好了。处理完后返回response。

回到了WSGIHandler,设置http返回的headers,然后直接返回response。

WSGIHandler整个看完了,现在要详细看的好多了。

url的解析部分。
setting middleware里django的默认设置都做了什么。
wrapped_callback调view也看一下。(make_view_atomic这里是数据库事务相关内容)
还有没看懂的signal,以前也没接触过。

上一篇:
下一篇:

相关文章:

Categories: 博客记录

0 Responses so far.

Leave a Reply