Pyhton全栈的知识点(5)

1. 对于django来讲，内部组件特别多，自身功能强大，有点大而全,而flask，内置组件不多，可是它的第三方组件不少，
    扩展性强，有点短小精悍，而它们之间也有类似之处，
　　由于它们两个框架都没有写sockte，都是基于wsgi协议作的，在此以外，flask框架中的上下文管理较为耀眼。
　　
　　相同点：它们两个框架都没有写sockte，都是基于wsgi协议作的
　　请求相关数据传递的方式不一样：django：经过传递request参数取值
　　　　　　　　　　　　　　　　flask： request的模块
　　　　　　　　　　　组件不一样：django组件多
　　　　　　　　　　　　　　　　flask组件少，第三方组件丰富
    注意: 使用上下文管理机制
    -threading.local()/greenlet.get_current()？---》Local的做用？
    做用：为每一个线/携程程建立一个独立的空间，使得线程对本身空间中的数据进行操做(数据隔离)。
    应用：DBUtils中为每一个线程建立一个数据库连接时使用
    -如何获取一个线程的惟一标记：threading.get_ident()
    -再次根据线程惟一标记，设置一个大内存字典的key，值就是线程空间中的数据
        -DBUtils线程池的模式也是为每一个线程建立一个连接
    -SQLAlchemy的create_engine也会建立线程池以供使用

2. session 
    两个Local和LocalStack分别对应ctx和app_ctx
    请求上下文管理（ctx）：request，session 
    应用上下文管理(ap_ctx)
        - 请求到来以后wsgi会触发__call__方法，由__call__方法再次调用wsgi_app方法
        - 在wsgi_app方法中：
            - 首先将 请求相关+空session 封装到一个RequestContext对象中，即：ctx。
            - 将ctx交给LocalStack对象，再由LocalStack将ctx添加到Local中，Local大字典结构：
                __storage__ = {
                    1231:{stack:[ctx] }
                }
            - 根据请求中的cookie中提取名称为session_id对应的值，对cookie进行加密+反序列化，再次赋值给ctx中的session
            
            -> LocalStack获取Local中的数据后，视图函数经过LocalProxy，获取LocalStack中相对应的值
            - 增删改查
            - 把session中的数据再次写入到cookie中。
            - 将ctx删除
        - 结果返回给用户浏览器
        - 断开socket链接

3. 问题：
    为何要把 ctx=request/session    app_ctx = app/g  分开?
      答：编写离线脚本时，须要配置文件，而配置文件存放在app中，并不须要请求相关数据　
        因此把app和请求相关的数据分开。若是只是须要g传递数据，则在g的生命周期中彻底够用     
    在web runtime时，栈中永远只有一个ctx,或者app_ctx;
        在使用离线脚本时，则可能存在多个，可是数据并不会混杂，经过with语句和top取值(-1)能够分层次获取   

4. Flask中g的生命周期？
    在请求触发__call__调用wsgi_app时，生成app_ctx=AppContext(app，g)
    在请求结束时app_ctx.pop()结束g

5. g和session同样吗？
    g是在有请求时被建立，请求结束时删除，下次请求又是一个新的g
    session会被加密序列化写入用户cookie，下次请求解密反序列化就有

6. g和全局变量同样吗？
    全局变量在程序启动时只生成一次，有且只有这一个变量
    g在请求时被生成，请求结束时被删除，是临时可建立变量

7.依赖的wsgi(服务器网关接口): werkzurg

8. 配置文件
    能够设置一个跟Django差很少的settings配置文件，经过app.config.from_object("settings.xxx")路径，
    具体实现是经过importlib模块和getattr反射找到“字符串路径”，再引用配置相关信息
    
9. 路由系统 
    -基于装饰器实现的路由系统
    -endpoint,反向生成URL，默认函数名
    -url_for("函数名" or endpoint)--------注意endpoint反向生成url时有同名,
        须要导入import functools -> @functools.wraps(func) 保留原函数的原信息
    -functool.partial   偏函数(减小用户输入函数参数)
    -动态路由：@app.route("/index/<int:nid>")   传递参数使用
10. 视图
     -基于反射区别method请求
    -FBV
        路由设置：@app.route("/xxxx")
    -CBV
        methods = ["GET",]        decorators = ["wrapper"]
        路由设置：app.add_url_rule("/xxx", None, UserView.as_view('aaa'))
11. 请求相关
        # 请求相关信息
        # request.method    request.path
        # request.args      request.full_path
        # request.form      request.url
        # request.values    request.files
        # request.cookies   request.headers
12. 响应 
    响应体：
        return "字符串"      return jsonify({"k1": "v1"})
        return render_template("xx.html")
        return redirect("/xxxx")
    定制响应体：
        -面向对象的封装
        obj = make_response("字符串")
        obj.headers["k1"] = "v1"
        obj.set_cookie("key", "value")
        return obj
    设置全局访问权限：
    @app.before_request
    def xxx():
        if request.path == '/login':
        return None

        if session.get('user'):
        return None

        return redirect('/login')
13. 模板渲染
    -基本数据类型：能够执行python语法
    -传入函数:
        -django， 自动执行
        -flask， 须要手动加括号执行
    -全局定义函数
        @app.template_global()
        def xx(a1, a2):
            # {{sb(1,9)}}
            return a1 + a2
    -添加撒选条件
        @app.template_filter()
        def db(a1, a2, a3):
            # {{ 1|db(2,3) }}
            return a1 + a2 + a3
    -模板继承跟django差很少
    -预约义模块(不传值看不见，传值就启动)
    -安全
        - 前端： {{u|safe}}
        - 后端： MarkUp("asdf")
　　　　　
14. 闪现
    -在session中存储一个数据，读取时经过pop将数据移除,获取的值返回给用户

15. 中间件 
    - call方法何时触发？
        - 用户发起请求时，才执行。

16. 蓝图（blueprint）
    -目标：给开发者提供目录结构
    其余：
        - 自定义模板、静态文件
        - 某一类url添加前缀
        - 给一类url添加before_request
            
17. 特殊装饰器
     -放在列表，循环执行
    1. before_request      (请求相关)
    2. after_request
    3. before_first_request

    4. template_global      (模板相关)
    5. template_filter

    6. errorhandler   (能够自定义错误信息)

18.before_request的执行时机（源码实现：存放在一个列表）Local执行以后，视图执行以前

19. threading.local (DBUtils组件建立一个线程池)

20. 为何导入request，就可使用？
    每次执行request.xx方法时，会触发LocalProxy对象的__getattr__等方法，由方法每次动态的使用
    LocalStack去Local中获取数据。

21.扩展：
    1. flask-session 
    2. DBUtils       其余地方也可使用
    3. wtforms
    4. sqlalchemy