Flask 扩展开发

Flask，一个微框架，通常需要一些重复的步骤来让第三方库工作。因为在很多时候， 这些步骤可以被分离出，来支持多个项目，就有了 Flask Extension Registry 。

如果你想要为还没有的功能创建你自己的 Flask 扩展，这份扩展开发指南会帮助你 在很短的时间内让你的应用跑起来并且感到像用户一样期待你的扩展运转。

所有的扩展都位于一个叫做 flask_something 的包，其中“ something ”是你 想要连接的库的名字。那么，例如当你计划要为 Flask 添加一个叫做 simplexml 的库的支持时，你应该把你扩展的包命名为 flask_simplexml 。

实际的扩展名（人类可读的名称）无论如何会是“Flask-SimpleXML”之类的东西。 确保在名字中包含“Flask”并注意大小写。这是用户可以在他们的 setup.py 文 件中注册你的扩展为依赖的方式。

Flask 设立了一个叫做 flask.ext 的重定向包，用户应该从这个包导入 扩展。例如，如果你有一个叫做 flask_something 的包，用户应该用 flask.ext.something 的方式导入。这样做是为了从老命名空间的包过度。 详情见 扩展导入的过渡 。

但是扩展如何看起来像扩展？一个扩展必须保证它可以同时在多个 Flask 应用中工 作。这是必要条件，因为许多人会使用类似 应用程序的工厂函数 的模式来创建 应用来进行单元测试或是支持多套配置。因此，你的应用支持这种行为非常重要。

最重要的是，扩展必须与一个 setup.py 文件一起装配，并且在 PyPI 上注册。同 样，开发 checkout 链接也应该能工作，这样才可以在 virtualenv 中容易地安装开 发版本，而不是手动下载库。

Flask 扩展必须以 BSD 或 MIT 或更自由的许可证来许可，这样才能被列入到 Flask Extension Registry 。记住 Flask Extension Registry 是一个人工维护的地方， 并且会视这些库的行为来决定是否进行必要的提前审查。

那么让我们开始创建这样一个 Flask 扩展。我们这里想要创建的扩展会提供 SQLite3 最基础的支持。

首先我们创建下面的目录结构:

这里是最重要的文件的内容:

下一个绝对需要的文件是 setup.py ，用于安装你的 Flask 扩展。你可以使用下 面的内容:

这有相当多的代码，但是你实际上可以从现有的扩展中直接复制/粘贴，并修改相应的 内容。

现在这个是你的扩展放代码的位置。但是这样一个扩展到底看起来是什么样？ 最佳实践是什么？继续阅读，你会有一些认识。

许多扩展会需要某种类型的初始化步骤。比如，想象一个应用像文档中建议的一样 (在 Flask 中使用 SQLite 3) 正在连接到 SQLite。那么，扩展如何获知应用对象的名称？

相当简单：你传递应用对象到它。

有两种推荐的初始化应用的方式:

初始化函数:

用什么取决于你想要什么。对于 SQLite 3 扩展，我们会使用基于类的方法，因为它 提供用户一个可以承担打开和关闭数据库连接的对象。

关于类，重要的是它们鼓励在模块层内共享。这种情况下，对象本身在任何情况下 不得存储任何应用的特定状态，而必须可以在不同的应用间共享。

下面是用来复制/粘贴的 flask_sqlite3.py 的内容:

那么这是这些代码做的事情:

__init__ 方法接受一个可选的应用对象，并且如果提供，会调用 init_app 。

init_app 方法使得 SQLite3 对象不需要应用对象就可以实例化。这个方法 支持工厂模式来创建应用。 init_app 会为数据库设定配置，如果不提供配置，默 认是一个内存中的数据库。此外， init_app 方法附加了 teardown 处理器。 它会试图使用新样式的应用上下文处理器，并且如果它不存在，退回到请求上下文处理 器。

接下来，我们定义了 connect 方法来打开一个数据库连接。

最后，我们添加一个 connection 属性，首次访问时打开数据库连接，并把它存储 在上下文。这也是处理资源的推荐方式：在资源第一次使用时惰性获取资源。

注意这里，我们把数据库连接通过 _app_ctx_stack.top 附加到应用上下文 的栈顶。扩展应该使用上下文的栈顶来存储它们自己的信息，并使用足够复杂的 名称。注意如果应用使用不支持它的老版本的 Flask 我们退回到 _request_ctx_stack.top 。

那么为什么我们决定在此使用基于类的方法？因为使用我们的扩展的情况看起来 会是这样:

你之后可以在视图中这样使用数据库:

同样地，如果你在请求之外，而你在使用支持应用上下文 Flask 0.9 或之后的版本， 你可以用同样的方法使用数据库:

在 with 块的最后，销毁处理器会自动执行。

此外， init_app 方法用于支持创建应用的工厂模式:

记住已审核的 Flask 扩展需要支持用工厂模式来创建应用（下面会解释）。

init_app 的注意事项

如你所见， init_app 不分配 app 到 self 。这是故意的！基于 类的 Flask 扩展必须只在应用传递到构造函数时在对象上存储应用。这告诉扩 展：我对使用多个应用没有兴趣。

当扩展需要找出当前的应用且它没有一个指向其的引用时，必须使用 current_app 上下文局域变量或用一种你可以显式传递应用的 方法更改 API 。

在上面的例子中，在每个请求之前，一个 sqlite3_db 被分配到 _app_ctx_stack.top 。在一个视图函数中，这个变量可以使用 SQLite3 的属性 connection 来访问。在请求销毁时， sqlite3_db 连接被关闭。 通过使用这个模式， 相同 的 sqlite3 数据库连接在请求期间对任何需要它的东 西都是可访问的。

如果 _app_ctx_stack 因为用户使用了老版本的 Flask 不存在， 建议退化到限定在请求中的 _request_ctx_stack 。

这只在你想要支持 Flask 0.6 和更老版本时有关

由于在 Flask 0.7 中关于在请求的最后运行的函数的变更，你的应用需要在此格外 小心，如果要继续支持 Flask 的更老版本。下面的模式是一个兼顾新旧的好方法:

严格地讲，上面的代码是错误的，因为销毁函数接受异常且典型地不返回任何东西。 尽管如此，因为返回值被丢弃，这刚好会工作，假设中间的代码不触碰传递的参数。

本文档只接触了扩展开发中绝对的最小部分，如果你想要了解更多，一个非常好的 主意是查看 Flask Extension Registry 上已有的扩展。如果你感到失落，也有 邮件列表 和 IRC 频道 来获取一些漂亮 API 的想法。特别是当你在做之前 没人做过的东西，这会是一个非常好的主意来获得更多投入。这不仅获得人们会想 从扩展中得到什么的想法，也可避免多个开发者重复发明轮子。

记住：良好的 API 设计是困难的，所以请在邮件列表里介绍你的项目，让 其它开发者在 API 设计上助你一臂之力。

最好的 Flask 扩展是那些为 API 共享通用风格的扩展，并且这只在起初就协作时 奏效。

Flask 也有已审核的扩展的概念。已审核的扩展被作为 Flask 自身的一部分来测 试来保证在新版本中不会破坏。这些已审核的扩展会在 Flask Extension Registry 中列出，并有相应的标记。如果你想要自己的扩展 通过审核，你需要遵守下面的指导方针:

一段时间，我们推荐对 Flask 扩展使用命名空间包。这在实践中被证明是有问题 的，因为许多不同命名空间包系统存在竞争，并且 pip 会自动在不同的系统中切 换，这给用户导致了许多问题。

现在，我们推荐命名包为 flask_foo 替代过时的 flaskext.foo 。Flask 0.8 引入了重定向导入系统，允许从 flask.ext.foo 导入，并且如果 flaskext.foo 失败时，会首先尝试 flask_foo 。

Flask 扩展应该力劝用户从 flask.ext.foo 导入，而不是 flask_foo 或 flaskext_foo ，这样扩展可以迁移到新的包名称而不烦扰用户。