WebCore 2.0.4

依赖项和附加项

WebCore 仅依赖于优秀的webob包提供请求、响应和 HTTP 状态码异常帮助器以及用于插件管理的m m.package实用程序包。所有其他依赖项将是应用程序依赖项；模板引擎、数据库层、会话存储机制甚至调度方法的选择完全取决于开发人员使用框架。提供了一些额外的要求，您可以在从命令行安装期间或在您自己的包的 install_requires中使用附加到包名称的逗号分隔列表来定义这些要求。例如，要在安装 WebCore 的同时安装一组典型的开发工具，请运行：

pip install WebCore[development]

可用的附加功能是：

• development - 这会安装一组推荐的开发时包，包括 pytest和一套插件，加上 backlash交互式调试器（可选 DebugExtension需要）、对象调度、全面的ptipython升级 REPL 和 女服务员开发网络服务器。

• 生产——安装推荐的生产时间包；目前这只安装了flup FastCGI服务器桥。

调度的默认选项被允许作为额外的：

• object – 安装对象调度

• route – 安装基于路由的调度

• traversal – 安装遍历调度

您还可以将支持的服务器网桥命名为额外的。当前可用的具有第三方依赖项的网桥包括：

• 女服务员

• 龙卷风

• 扑通

开发版

开发在GitHub上的 WebCore项目中进行。那里提供了问题跟踪、文档和下载。Freenode在#webcore 频道中慷慨地提供了开发聊天（WebCore 的开发和使用 WebCore 开发自己的解决方案的用户的聊天） 。

安装当前的开发版本需要Git，一个分布式源代码管理系统。如果您有 Git，您可以运行以下命令来下载开发版本并将其链接到您的 Python 运行时：

git clone https://github.com/marrow/WebCore.git
pip install -e WebCore

然后，您可以随时升级到最新版本：

(cd WebCore; git pull; pip install -e .)

额外的依赖可以声明为与基于 Web 的安装相同：

pip install -e WebCore[development]

如果您想进行更改并将其贡献回项目，请分叉 GitHub 项目，进行更改并提交拉取请求。此过程超出了本文档的范围；有关更多信息，请参阅 GitHub 的文档。

应用

Application类是 Web 框架的主要入口点。它的构造函数目前最多需要三个参数：

• root – 用作/请求控制器的根对象

• extensions – 与您的应用程序一起使用的扩展列表

• logging – Python日志记录配置

“根控制器”用作请求端点分派解析的起点，请参阅下面的“控制器”部分以了解此处可以使用的详细信息，但它基本上是任何东西。

默认BaseExtension提供基本的请求和响应对象以及基本视图，始终为您的应用程序启用，没有配置，也不需要自己实例化。其他扩展应该被实例化并在扩展列表中传递。

日志配置提供了两种选择：简单的“全局日志级别”，将日志定义为一个字典，只包含一个级别键来命名要设置的级别，或者完整的logging.config.dictConfig配置。仅传递一个级别相当于运行logging.basicConfig。

此配置可以完全来自 YAML，例如：

root: !!python/name:web.app.example.RootController

extensions:
    - !!python/object:web.ext.debug.DebugExtension
    - !!python/object:web.ext.analytics.AnalyticsExtension
    - !!python/object:web.ext.annotation:AnnotationExtension

logging:
    level: debug

这将使管理复杂的扩展配置更容易。使用这样的配置调用 WebCore，同时允许区分生产和开发环境并在 ModWSGI 下使用的一种方法是：

import yaml
from web.core import Application

fname = 'development.yaml' if __debug__ else 'production.yaml'
with open(fname, 'r', encoding='utf-8') as fh:
    config = yaml.load(fh)

app = Application(**config)

if __name__ == "__main__":
    app.serve('wsgiref')

现在，运行python run.py（如果保存为run.py）将为development.yaml配置提供服务，并以python -O run.py（启用优化）或在环境中设置PYTHONOPTIMIZE=1运行将利用生产。 yaml文件。

WebCore 在启用优化的情况下高度感知运行，消除了许多仅在开发中真正有用的昂贵的验证检查。例如，使用无效参数调用端点在开发中会出现404并带有友好警告，但在生产中会出现500 ，因为TypeError没有被抢先检查和捕获；这是最昂贵的验证检查之一。如果 __debug__阻塞，请随意浏览代码 以查看“生产模式”中的其他变化。

您定义扩展的顺序无关紧要；它们声明依赖关系，并在收集回调时自动进行依赖排序。请参阅extension.py示例以获取有关您可以使用它们做什么的更多信息。

语境

整个应用程序有一个与之关联的ApplicationContext 。该对象被传递给各种扩展回调并充当属性访问字典。（所有典型的字典方法都可以使用，并且可以将键作为属性访问，从而节省一些输入。）在处理请求期间，构造了一个称为RequestContext和请求内扩展回调的子类，并且您的控制器端点是给出了这个例子的参考。

基础ApplicationContext中存在的属性是：

• app – 对Application实例的引用

• root – 构造Application实例时传递的原始对象

• 扩展- WebExtensions扩展注册表

• dispatch – WebDispatchers调度协议桥和插件注册表

• view – WebViews视图处理程序注册表

扩展将在启动和停止事件期间访问这些，例如注册新的视图处理程序。

RequestContext中存在的属性（由 WebCore 本身或请求处理期间的BaseExtension添加）是：

• environ – 传递给 WebCore 的 WSGI 处理程序的 WSGI 请求环境

• request –表示当前 HTTP 请求的webob.Request

• response – WebCore 将返回的响应对应的webob.Response对象

• path – 由(handler, script_name)的元组表示的调度步骤列表

其他扩展可能会添加其他属性。

控制器，端点，调度，哦，我的！

控制器，更一般地说，可调用端点，是调用以处理请求并返回值以供查看或引发异常的函数或方法。非方法可调用对象作为第一个参数传递给上下文；假设方法可以通过self访问，因为上下文将作为唯一的位置参数传递给类构造函数。可调用端点还额外传递任何未处理的路径元素作为位置参数，以及查询字符串参数（GET值）和表单编码的正文元素（POSTvalues) 作为关键字参数，请求正文中的参数优先，重复的键作为值列表传递。它们可以返回注册了视图的任何值，有关详细信息，请参阅 视图管理器的文档字符串。

另一方面，静态端点是可以由视图处理的不可调用对象。本文档顶部的第一个示例依赖于这样一个事实，即有一个视图来处理字符串，包括静态字符串以及由可调用端点返回的字符串，例如：

def hello(context):
    return "Hello world!"

为了允许自定义名称，您可以将此端点编写为：

def hello(context, name="world"):
    return "Hello {}!".format(name)

如应用程序部分所述，当 Python 在启用优化（-O或PYTHONOPTIMIZE集）的情况下运行时，传递的未知参数（未知的查询字符串参数或表单值）将导致TypeError被引发，因此500 Internal Server Error由于未捕获的异常。在开发中（没有优化） ，结果将是404 Not Found错误，并带有指示不匹配值的消息。您可以使用*args 和**kwargs来捕获任何其他未定义的位置和关键字参数，或者使用扩展来改变传入数据并在调用端点之前去除无效参数。

但是，可以通过几种不同的方式之一调用“hello world”端点，因为没有设置其他限制：

• GET / - 世界你好！（默认使用。）

• 获取/爱丽丝- 你好爱丽丝！（按位置通过。）

• GET /?name=Bob – 你好，鲍勃！（通过查询字符串分配。）

• POST /提交带有名称字段和 Eve 值的表单- Hello Eve！（通过表单编码的正文分配。）

其他 HTTP 动词也可以工作，但只有在POST请求上才需要和处理表单编码的正文。

查找用于处理请求的端点的过程称为dispatch。有许多可用的调度形式，有些应该立即熟悉。

• 对象分派。这是 WebCore 的默认调度形式（由 web.dispatch.object包提供），也被其他几个框架使用，例如 TurboGears。本质上，每个路径元素都作为先前查找对象的属性进行查找，将/foo/bar/baz之类的路径视为解析 Python 引用root.foo.bar.baz的尝试。这是非常灵活的，允许使用 Python 标准协议（例如__getattr__方法）轻松重定向下降，使用惰性评估描述符等。

• 注册的路线。这可能是从 PHP 框架转换或使用过 Python 中任何主要的宏或微框架（如 Django、Flask 等）的开发人员最熟悉的方法。您显式映射 URL，通常使用正则表达式或正则表达式简写，指向特定的可调用端点。通常这是使用装饰器完成的。WebCore 通过web.dispatch.route包提供这种形式的调度 。

• 遍历。这类似于对象分派，但通过映射键下降。前面的示例然后转换为root['foo']['bar']['baz'] ，允许通过__getitem__协议进行管理下降。这是 Pyramid 提供的一种方法（另一种是路由）。我们通过web.dispatch.traversal包提供这种形式的调度 。

可能还有其他可用的调度程序，并且该协议允许“调度中间件”提供更灵活的端点查找方法。调度协议本身与框架无关（这些示例调度程序绝不是 WebCore 特定的）并且 有自己的文档。

2.0 版

• 从头开始对 WebCore 的完全现代化重写。

• 具有多个扩展接口来扩展注册的视图处理程序并提供统一的回调机制。

• 标准用法不使用超全局变量或“线程局部变量”，而是依赖于由扩展协作填充的上下文对象。

• WebCore 以前的“方言”系统现在正在调度。

2.0.1 版

• 谢谢皮皮。

版本 2.0.2

• 更正了转换扩展回调的参数规范，按照 #163修复了AnnotationExtension的使用。

• 额外的源代码级文档和扩展示例。

• 过多的额外 WSGI 服务器适配器；现在支持的是：waitress tornado、fcgi、 cherrypy、appengine、paste、 eventlet、gevent、diesel和bjoern。每个都可以作为extras_require以相同的名称使用，这将引入所需的第三方依赖项。

版本 2.0.3

• 参数处理从web.core移到扩展变异处理程序中。功能改进了查询字符串和表单编码正文参数的丰富展开。可配置的行为。详情见： web/ext/args.py

• 广泛记录的访问控制列表扩展使用上下文感知谓词验证端点安全和返回值权限。

• 扩展定义收集的额外回调的能力。

• DatabaseExtension（以前称为DBExtension）已移至其自己的存储库中。

• 内容协商端点返回值序列化，带有可插入转储注册表。

• 完整的单元测试覆盖率。

版本 2.0.4

• 更正了调度事件的基本扩展处理中未能省略尾部斜杠的问题。通过不匹配的路径处理导致错误的空字符串位置参数。第195章

麻省理工学院许可证

版权所有 © 2006-2020 Alice Bevan-McGregor 和贡献者。

特此免费授予任何人获得本软件和相关文档文件（“软件”）的副本，以不受限制地处理本软件，包括但不限于使用、复制、修改、合并的权利、发布、分发、再许可和/或出售本软件的副本，并允许向其提供本软件的人这样做，但须符合以下条件：

上述版权声明和本许可声明应包含在本软件的所有副本或大部分内容中。

本软件按“原样”提供，不提供任何形式的明示或暗示保证，包括但不限于适销性、特定用途适用性和非侵权性保证。在任何情况下，作者或版权持有人均不对任何索赔、损害或其他责任承担任何责任，无论是在合同、侵权或其他方面，由本软件或本软件的使用或其他交易引起或与之相关。软件。