pylons 中 wsgiapp 和 wsgicontroller 的关系

阅读更多

 

pylons 看了好久了,喜欢的他精简封装,就想它自己的名字一样,“ 架线塔 ” 松散话。说是框架,其实也不是框架。

 

只是把一些模块结合起来,随着对pylons的了解的越来越深入,越着迷。其中好些信息看文档是不深入的,一些疑惑

 

还是要看pylons的源码的(别怕,pylons的源码核心没多少),说回来,python的web开发不都是围绕wsgi 走的吗?

 

本质就不复杂,有些框架复杂,是外围太庞大了,把本质掩盖在里面。

 

pylons 的核心就是 “ 垂直的 Middleware + 横向的 Controller ”

 

Middleware  就像是千层饼 外部的 “ 层饼 ”

Controller    就是里面的 “ 馅 ”

 

有 “ 肉馅千层饼” , “豆沙千层饼” ...... 

 

Middleware 在系统级别上 垂直复用。 Controller 在应用逻辑级别上 平行处理

 

 

一些关键点:

 

 

1、程序的入口:

 

$app\config\middleware.py 中的 

 

 

make_app(global_conf, full_stack=True, static_files=True, **app_conf):

 

 

 global_conf 等一系列参数,都是通过解析配置文件得到的。

 

   

  config = load_environment(global_conf, app_conf) 中 把 route 的mapper 也包含在里面了。

  这个config 可以说是运行环境了。

   

 接下来关键点

 

2、 app诞生

 

 

 app = PylonsApp(config=config)
 

 

    app 被注入运行环境,各种参数和处理逻辑。但是这个时候也只是 “被注入”了而已,程序还没运行。

 

    然后一系列的链式 Middleware 一层一层的引用封装。

 

    这个时候 Middleware  垂直体系已经建立。wsgiapp 完成。但是还没有run。

 

 

3、run

 

    所有的python框架再怎么变化,最后都要有这么一个轮回,app毕竟只是app,它要在服务容器中运行。

 

    当然,这外部容器五花八门,这里不是重点,不多讲,wsgi app的命运是要被外部 调用的。

 

    app 的  __call__(self, environ, start_response) 方法被调用。

 

    刚才说,app 外面包了很多层的 Middleware ,所以这个按 “ 先进后出 ” 的方式 一层一层调用。

 

   Middleware 调用到最后,到最底层  PylonsApp 里面的  __call__,又一个关键点

 

 

controller = self.resolve(environ, start_response)

 

    Controller 诞生。根据信息,找到 调用的 Controller

    下一步

 

response = self.dispatch(controller, environ, start_response) 

 

    调用 Controller 产生 response ,

 

     然后再一层一层 由外部的 Middleware 再对 response 处理。

 

 

 

所以,这里 Controller 在整个体系的只占很小一部分,也是pylons 让用户去写逻辑的一部分。

 

所以各种应用,各种形式的 只要满足 wsgi 都可以在pylons 上跑,因为pylons 已经把逻辑抽离出来了。

 

对 Pyamf 的困惑也游刃而解,Pyamf 对 pylons 的支持 只不过 按照自己的需要 定制了一个 自己的 Controller

而已, pylons 的众多特性已经在使用当中。

 

感受到此结束,enjoy !!

 

 

 

 

 

 

 

 

 

 

你可能感兴趣的:(pylons 中 wsgiapp 和 wsgicontroller 的关系)