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 ！！