这里主要分析Flask对象实例化后,整个应用的启动过程都发生了什么。
1.执行app.__call__方法:
2.执行app.wsgi_app():
这一步都做了什么?
self.request_content(environ)
实例化RequestContext对象
1处做了什么?
调用 app.create_url_adapter 方法,把 app 的 url_map 绑定到 WSGI environ 变量上。
最后会调用 match_request 方法,这个方法调用了 url_adapter.match 方法,进行实际的匹配工作,返回匹配的 url rule。
定义与request相关的g变量
说明:处理请求时用作临时存储的对象(Appcontext类型)
接下来执行RequestContext对象的push方法:
分析:
1刚开始是None;
2.实例化APPContext对象
3.执行APPcontext对象的push方法
创建LocalStack对象,也就是创建一个栈,把AppContext对象压入栈中
然后:
把RequestContext对象压入到LocalStack中(和上面是两个栈)
push方法都做了什么?
.......夜深了,回头补充
紧接着:
执行Flask对象的open_opensession()方法
调用了app的open_session:
SecureCookieSessionInterface().open_session()
接着看都做了什么?
def open_session(self, app, request):
#获取加解密对象
s = self.get_signing_serializer(app)
if s is None:
return None
# 从cookies中获取cookie的名字:'session'
val = request.cookies.get(app.session_cookie_name)
if not val:
#如果val为空,则返回SecureCookieSession对象,相当于{}
#session_class = SecureCookieSession
return self.session_class()
max_age = total_seconds(app.permanent_session_lifetime)
try:
# 解密返回原始数据
data = s.loads(val, max_age=max_age)
#session_class = SecureCookieSession相当于{},根据代码追溯可以发现,基类继承dict
#"""Base class for sessions based on signed cookies."""
#翻译一下:基于加密cookies的session基类
return self.session_class(data)
except BadSignature:
return self.session_class()
3.接下来执行:
未完....