Zope3教程-Zope和部件体系架构
Zope3教程-Zope和部件体系架构
http://www.315ok.org/blogfolder/107
http://www.315ok.org/logo.png
Zope3教程-Zope和部件体系架构
Zope3教程-Zope和部件体系架构
[align=center][size=6]Zope 和部件体系架构[/size] [/align]
[align=left]本章将从一个视角来探讨Zope发布环境。将解释Zope怎样工作以及部件体系架构的原理。在继续下一章前，肯定你理解了本章介绍的基本概义。
[/align][size=5]Zope 怎样工作
[/size]
[/size]
当我们采用象Zope这样大的框架时目的是避免程序开发的杂乱无章。这意味着Zope应用开发力求代码的重用，通过定制或扩展已有的功能模块来做快速开发。问题是怎么做才能尽可能的简单和灵活？
面向对象程序设计提供两种方法。
第一种是子类化。一个子类可以继承多个基类的功能，亦可覆盖某些功能。子类化当然是十分强大的概义，允许开发人员在一个类中综合多个功能。这种方法在zope中是个基础，zope2中许多类就是综合了多个类。子类化有个缺点：当你要作功能更改时，必须定义一个新的类，通常混合类的功能要由子类来实现，但是错误的元数据，更多时候，仅仅改变某些表现层行为，也意味着要重写python代码，即便是HTML模板的小小定制。
第二种是委派，委派是另外一个概义，通过将工作分配到几个独立的可以调用的部件来完成。每一个部件负责一个复杂的操作。例如，一个内容部件仅仅负责存储数据，而表现部件仅仅负责呈现发布的数据。当一个部件在通用性上不再合适，或者你需要特别的应用时，你可以用更好的实现来替换它。例如一个决定内容部件被呈现在浏览器端的表现部件可以被更换，而内容部件不用作任何修改。部件体系架构是zope强大而灵活的主要依据。为了用新的实现来替换，部件需要清楚地定义他们需要从其他部件得到什么功能，以及他们自己提供什么功能。在现实世界中，就象契约一样。对象为了成为体系结构中的部件，必须有清晰的契约。象其他开发语言系统一样，部件体系结构用接口来描述契约。因此我们用接口来定义对象作为部件。也就是说，要成为zope3体系结构的部件，必须要接口（和接口发生关系）。通常，我们将部件分为三类：模型、视图、控制（MVC）。模型描述数据的结构，驻留数据，通常称为内容部件。视图呈现数据给用户（例如GUI部件或WEB页面）。控制用于处理数据，用以改变模式或改变视图，也就是平常所说的逻辑层。在zope部件体系结构中，适配器能用来实现控制层和视图层。常用来扩展已有部件的数据处理逻辑和视图表现逻辑。另外，从适配器中分离一部分，在zope体系架构中,称为工具应用，它们作为部件履行某一任务，而不用依靠其他部件。例如，数据库查找和索引功能，就是工具应用。
[size=5]重用和可插拔的好处[/size]
采用部件体系架构有两个很大的好处：增加交互能力和易于重用。在zope中你可以用一个定制的部件替换任何部件。这种方式，可以应用到很小的部件，例如一个表现HTML的浏览器视图部件，也可以是很大的部件，例如zope的认证系统。另外的好处是重用已有的部件。 python拥有大量进行数据处理或表现的功能模块，zope为什么要阻止你使用它们呢？在zope 中要应用这些python包的功能，如HTML表现或支持另外的网络协议如FTP等，只需要添加部件。部件体系架构由 zope.component 包提供。下面逐个介绍通常的部件：
现在，大多内容管理系统使用关系数据库来存储数据。你在ZOPE中也能很好应用这些数据。ZOPE关心要发布的对象，通过用对象关系映射（ORM）将关系数据转换为对象。另外一种，用数据库存储相关数据进入对象，而不是存入关系数据库的表格。这就是对象数据库，ZOPE有这种数据库，ZODB.。通过ZODB，用很少的代码就能保存持续的python对象。ZODB完全遵守ACID 数据库标准。ZODB支持版本管理和可插拔的后台存储架构，（六章中将详细介绍ZODB）所有这些对于内容对象的开发人员是透明的，而且ZODB也能用在 ZOPE世界的外面。
组合部件到一起。
适配器工作就象立体声音响的匹配器，假设，你有一个旧事欧式录像机，你想接他到一个现代的功放上，功放需要一个RCA输入接口，但老式录像机是5针输出插头，为了连接它们，你可以去电子商店买一个5针插头到 RCA的转换器。对于放大器，它不关心音乐来自什么设备，只关心是通过RCA插进来就行。我们说功放接受任何提供RCA插头的音源设备，或者通过转换器转为RCA也是有效的。Zope 适配器的工作原理和这一样。即便一个对象不直接提供某一API，一个适配器可以用来为对象提供此种API。上述目录列表例子中，我们不奢望对象本身能告诉我们他的大小，但是我们能借用适配器来做这个工作。我们因此可以适配这个对象到一个提供size API的接口。
通过这种方法，适配器让我们不用更改原始代码来扩展已有部件功能。适配器很少要求某些特别的实现，仅仅实现它们所适配和提供额的口即可。
视图
视图是扩展部件表现能力的一种特别的适配器。视图连接应用部件和用户，作为用户明显不知道怎样和部件沟通，zope 作为一个WEB应用平台，视图当然是适配器的一种重要应用情况。视图作为一种多适配器和它所表现的内容部件一样：它应该能用一个提供同样接口的不同的实现来替换。简单说，视图不依靠某种实现。因此，它们为接口而被注册。正如我们稍后看到的，这种注册不用python来做，而是用特别的配置文件，这样站点管理员不用写代码就能允许或取消视图注册。这一特性，同样适用于其他适配器和其他类型部件。适配器将在11章详细介绍，视图在7章说明，并在13章再次说明。
通常我们能区分适配器或工具应用取决于是否依靠上下文。上下文相关的部件是适配器，上下文无关的部件是工具应用。因此，工具应用不需要上下文参数。
单独的 和命名的 工具应用
工具应用有两种使用情况。
第一种，某一功能类型被一个应用所需要而注册为一个单独的工具应用（意味着每站点一个实例或每应用一个实例），它们单单通过接口被注册和查询，这种类型的工具应用如：
[/align]
[/size][align=left] 如果我们要查找部件，必须先注册在某地方，这个工作由部件注册来完成。（通常由站点管理员操作）有时一个简单的注册，也需要定义其他的应用逻辑。 zope3简单地调用应用逻辑（包括部件注册）配置。这种配置怎么发生？确切的说，部件本身并不负责自身配置。一个部件怎么知道在哪里被注册，它是否将被注册。另外，这样的配置通常不由站点开发人员负责，而应由站点管理人员负责。配置文件书写应该脱离python。 Zope3 采用基于XML的配置语言来做全局部件注册：称之为ZCML，采用格式化文本形式，而不是代码形式进行配置。开发人员不能将配置和实现混在一起。另外，XML是个WEB标准，许多文本编辑器可以对其进行编辑，方便站点管理员不用写python代码就能启用、取消甚至替换部件。
[/align][size=5]安全体系
[/size] 数据存储、处理、呈现是应用的一部分。基于认证，允许或拒绝某些功能是另一个概义。安全在WEB应用当中扮演重用角色。本章将简要介绍zope安全体系的基本概义，详细介绍在21章。
在ZOPE中，最小的安全声明单位是权限。大多数部件在执行特定操作时，要求特定的权限。例如，访问一个内容对象的数据要求这种权限，修改数据需要那种权限。部件本身并不关心谁有什么权限，而是由站点管理员来设置这些策略。在 Zope中，主体是带有某种访问权限的实体，通常我们说主体是指带有帐号的用户。
主体由认证插件提供，认证工具查询该插件（部件）。一个定制的认证插件，主体可以定义在任何地方，比如文件系统、关系数据库等，主体的登录信任被登录信任工具抽取，另外主体也能组合近逻辑的组。
在Zope，安全策略决定什么时候允许什么时候拒绝某一特权。当判断时，它检查激活的安全主体是否有权限执行操作。象其他部件一样，安全策略是可以插拔的，这意味着，你可以实现你直接的安全策略来实现应用的要求。
[align=left]本章将从一个视角来探讨Zope发布环境。将解释Zope怎样工作以及部件体系架构的原理。在继续下一章前，肯定你理解了本章介绍的基本概义。
[/align][size=5]Zope 怎样工作
[/size]
- 服务器。服务器是由客户端发出请求，让用户连接到Zope 的部件。
- 发布器。由服务器进来的请求被发布器操作。
- 应用。除了服务器和发布器外，其他都是属于应用范畴。
[/size]
当我们采用象Zope这样大的框架时目的是避免程序开发的杂乱无章。这意味着Zope应用开发力求代码的重用，通过定制或扩展已有的功能模块来做快速开发。问题是怎么做才能尽可能的简单和灵活？
面向对象程序设计提供两种方法。
第一种是子类化。一个子类可以继承多个基类的功能，亦可覆盖某些功能。子类化当然是十分强大的概义，允许开发人员在一个类中综合多个功能。这种方法在zope中是个基础，zope2中许多类就是综合了多个类。子类化有个缺点：当你要作功能更改时，必须定义一个新的类，通常混合类的功能要由子类来实现，但是错误的元数据，更多时候，仅仅改变某些表现层行为，也意味着要重写python代码，即便是HTML模板的小小定制。
第二种是委派，委派是另外一个概义，通过将工作分配到几个独立的可以调用的部件来完成。每一个部件负责一个复杂的操作。例如，一个内容部件仅仅负责存储数据，而表现部件仅仅负责呈现发布的数据。当一个部件在通用性上不再合适，或者你需要特别的应用时，你可以用更好的实现来替换它。例如一个决定内容部件被呈现在浏览器端的表现部件可以被更换，而内容部件不用作任何修改。部件体系架构是zope强大而灵活的主要依据。为了用新的实现来替换，部件需要清楚地定义他们需要从其他部件得到什么功能，以及他们自己提供什么功能。在现实世界中，就象契约一样。对象为了成为体系结构中的部件，必须有清晰的契约。象其他开发语言系统一样，部件体系结构用接口来描述契约。因此我们用接口来定义对象作为部件。也就是说，要成为zope3体系结构的部件，必须要接口（和接口发生关系）。通常，我们将部件分为三类：模型、视图、控制（MVC）。模型描述数据的结构，驻留数据，通常称为内容部件。视图呈现数据给用户（例如GUI部件或WEB页面）。控制用于处理数据，用以改变模式或改变视图，也就是平常所说的逻辑层。在zope部件体系结构中，适配器能用来实现控制层和视图层。常用来扩展已有部件的数据处理逻辑和视图表现逻辑。另外，从适配器中分离一部分，在zope体系架构中,称为工具应用，它们作为部件履行某一任务，而不用依靠其他部件。例如，数据库查找和索引功能，就是工具应用。
[size=5]重用和可插拔的好处[/size]
采用部件体系架构有两个很大的好处：增加交互能力和易于重用。在zope中你可以用一个定制的部件替换任何部件。这种方式，可以应用到很小的部件，例如一个表现HTML的浏览器视图部件，也可以是很大的部件，例如zope的认证系统。另外的好处是重用已有的部件。 python拥有大量进行数据处理或表现的功能模块，zope为什么要阻止你使用它们呢？在zope 中要应用这些python包的功能，如HTML表现或支持另外的网络协议如FTP等，只需要添加部件。部件体系架构由 zope.component 包提供。下面逐个介绍通常的部件：
- 接口
- 按照契约，卖主履行他的承诺。
- 客户使用该契约来保障得到卖主的承诺。
- 双方都知道，通过契约，期望的事情将完成。
- 内容部件
现在，大多内容管理系统使用关系数据库来存储数据。你在ZOPE中也能很好应用这些数据。ZOPE关心要发布的对象，通过用对象关系映射（ORM）将关系数据转换为对象。另外一种，用数据库存储相关数据进入对象，而不是存入关系数据库的表格。这就是对象数据库，ZOPE有这种数据库，ZODB.。通过ZODB，用很少的代码就能保存持续的python对象。ZODB完全遵守ACID 数据库标准。ZODB支持版本管理和可插拔的后台存储架构，（六章中将详细介绍ZODB）所有这些对于内容对象的开发人员是透明的，而且ZODB也能用在 ZOPE世界的外面。
- 适配器
组合部件到一起。
适配器工作就象立体声音响的匹配器，假设，你有一个旧事欧式录像机，你想接他到一个现代的功放上，功放需要一个RCA输入接口，但老式录像机是5针输出插头，为了连接它们，你可以去电子商店买一个5针插头到 RCA的转换器。对于放大器，它不关心音乐来自什么设备，只关心是通过RCA插进来就行。我们说功放接受任何提供RCA插头的音源设备，或者通过转换器转为RCA也是有效的。Zope 适配器的工作原理和这一样。即便一个对象不直接提供某一API，一个适配器可以用来为对象提供此种API。上述目录列表例子中，我们不奢望对象本身能告诉我们他的大小，但是我们能借用适配器来做这个工作。我们因此可以适配这个对象到一个提供size API的接口。
通过这种方法，适配器让我们不用更改原始代码来扩展已有部件功能。适配器很少要求某些特别的实现，仅仅实现它们所适配和提供额的口即可。
视图
视图是扩展部件表现能力的一种特别的适配器。视图连接应用部件和用户，作为用户明显不知道怎样和部件沟通，zope 作为一个WEB应用平台，视图当然是适配器的一种重要应用情况。视图作为一种多适配器和它所表现的内容部件一样：它应该能用一个提供同样接口的不同的实现来替换。简单说，视图不依靠某种实现。因此，它们为接口而被注册。正如我们稍后看到的，这种注册不用python来做，而是用特别的配置文件，这样站点管理员不用写代码就能允许或取消视图注册。这一特性，同样适用于其他适配器和其他类型部件。适配器将在11章详细介绍，视图在7章说明，并在13章再次说明。
- 工具应用
通常我们能区分适配器或工具应用取决于是否依靠上下文。上下文相关的部件是适配器，上下文无关的部件是工具应用。因此，工具应用不需要上下文参数。
单独的 和命名的 工具应用
工具应用有两种使用情况。
第一种，某一功能类型被一个应用所需要而注册为一个单独的工具应用（意味着每站点一个实例或每应用一个实例），它们单单通过接口被注册和查询，这种类型的工具应用如：
- 数据库连接、索引、搜索
- 编码解码，加密解密
- 邮件投递，浏览器会话，翻译协商
- 排序，随机等等
[/align]
- 权限和角色
- 内容类型
- 翻译域
- 浏览器皮肤
[/size][align=left] 如果我们要查找部件，必须先注册在某地方，这个工作由部件注册来完成。（通常由站点管理员操作）有时一个简单的注册，也需要定义其他的应用逻辑。 zope3简单地调用应用逻辑（包括部件注册）配置。这种配置怎么发生？确切的说，部件本身并不负责自身配置。一个部件怎么知道在哪里被注册，它是否将被注册。另外，这样的配置通常不由站点开发人员负责，而应由站点管理人员负责。配置文件书写应该脱离python。 Zope3 采用基于XML的配置语言来做全局部件注册：称之为ZCML，采用格式化文本形式，而不是代码形式进行配置。开发人员不能将配置和实现混在一起。另外，XML是个WEB标准，许多文本编辑器可以对其进行编辑，方便站点管理员不用写python代码就能启用、取消甚至替换部件。
[/align][size=5]安全体系
[/size] 数据存储、处理、呈现是应用的一部分。基于认证，允许或拒绝某些功能是另一个概义。安全在WEB应用当中扮演重用角色。本章将简要介绍zope安全体系的基本概义，详细介绍在21章。
在ZOPE中，最小的安全声明单位是权限。大多数部件在执行特定操作时，要求特定的权限。例如，访问一个内容对象的数据要求这种权限，修改数据需要那种权限。部件本身并不关心谁有什么权限，而是由站点管理员来设置这些策略。在 Zope中，主体是带有某种访问权限的实体，通常我们说主体是指带有帐号的用户。
主体由认证插件提供，认证工具查询该插件（部件）。一个定制的认证插件，主体可以定义在任何地方，比如文件系统、关系数据库等，主体的登录信任被登录信任工具抽取，另外主体也能组合近逻辑的组。
在Zope，安全策略决定什么时候允许什么时候拒绝某一特权。当判断时，它检查激活的安全主体是否有权限执行操作。象其他部件一样，安全策略是可以插拔的，这意味着，你可以实现你直接的安全策略来实现应用的要求。