PCS308 Zope

概述

Zope3 的第一版在11月7日(2004年)发布了。这是Zope3项目史上的一个重大里程碑。或许很多人都想知道如果他们将要使用Zope3话，到底对他们意味着什么，以及"为什么要选择它"？需要吗？不需要吗...我将试图回答这个问题，或者至少，我提供足够多的信息，让人们自己来回答这个问题。

首先，我将追思Zope3的历史，讲述它一路走来的原由。

历史：Zope和前身

Zope最初是设计给非技术用户使用的，让他们很容易就能管理信息，创建动态的web应用。有几种途经可以达到这个目的，比如：

• 一个通过Web来管理数据、模板和脚本的环境
• 提供SQL方法和数据库连接，让它可以很easy的使用关系数据
• 一个内嵌的索引机制，让它可以很easy的提供搜索功能
• 获取机制，提供一个简单的方法可以从层层目录中共享信息；还有
• ZClasses，提供一个基本的方法，来创建新的content类型，并且/或者扩展已有的content类型以提供新的方法或者模板

上面的这些方法，对于大多数的web应用来说工作得非常好了。实际上，有一些老土的、非技术人员开发的内容管理系统（content-management systems），仅仅使用了我说的第一个方法。

原料::

使用Python给Zope带来的变化

然而，许多开发者并不满足于一个只是预先写好对象、通过web来定制的工具。对于这些开发者来说，必须有一整套开发工具和APIs的集合提供才行。比如他们才能构建额外的文件系统库，使用Python灵活的APIs。

对于Zope2的Python开发者们来说，已经有了一些显著的变化:

• Zope2这个framework非常复杂，这在很大程度上应归咎于应用领域的固有复杂性。Zope有许多特性，涵盖了从事务管理、安全性到标准元数据等方方面面。新Zope应用通常需要所有这些功能都协同工作。继承机制通常用来管理复杂事物，但是延伸的范围并不广。为了只提供最基本的功能，一个名叫 SimpleItem的类被提出来了。这个名字提醒人们，一个对象只需要提供最基本的功能就行了，而不要做过多额外的事，尽管这个基本类本身还有许多基类。这些基类为了方法的重载或者提供配置数据等不同的目的而被定制得专用化了。搞清楚哪些是要被重载的，哪些是要配置的，以及这些繁多的基类如何互相调用，这工作太难了。（真的是不可能的任务）

• 为了尽可能简单的提供丰富的功能（特别是对于非技术用户而言），Zope做了许多自动化的工作。这对于简单的应用是非常好的，但是对于那些更复杂些的应用，反而是一种障碍了。主要表现在以下方面：
  • 隐式获取（implicit acquisition）; 还有
  • 文档模板标记语言（Document Template Markup Language ，DTML）所用的名字空间堆栈
  • 利用这些便利性，用户可以不必严格的写明到哪里查找就能获得数据。大多数情况下这工作得很好，但是如果出现不可预料的命名冲突，它就很难查明相冲突的名字在哪里。就算它能运行，也很难说清楚它为什么能运行。
  • Zope提供了一种非常方便的安装第三方产品（products）的机制。不幸的是，它很难适用于所有的产品。在传统的Zope产品中，一个对象的所有功能都是它自己的类或者基类提供的。改变这些产品行为的唯一方式，是去修改或者子类化它们。修改产品并不是一个好主意，因为这让维护升级变得很困难。子类化也是令人讨厌的，因为它会让基类和子类之间耦合性得过于紧密了。（这就是众所周知的脆弱的基类问题。）Zope的CMF(Content- Management Framework)的一个最大的贡献在于它的工作机制，它能把呈现和业务逻辑分离，能与目标类无关的进行管理，并且可以很容易的实现用户化/定制。换句话说，这可以让呈现和业务逻辑在不修改源码和不使用继承的情况下就能被用户化/定制。

在2000年的晚些时候，Zope公司的工程师们想出了能让Zope更好的为开发人员服务的方法。主要是以下几个方面。

• 建立一个更好的模板系统，让开发者和网页设计师们能更容易的协同工作。在那个时候，Zope只有一个叫DTML的模板语言。DTML有一个大多数模板系统都会有的问题，那就是模板本身不是合法的web页面，不能用HTML编辑工具来编辑更新。一个设计师可以先做一个网页，但是在程序员插入代码让它变成动态页面后，它就失去控制了。我们工作的结果是设计出了一个更好的模板系统——ZPT（Zope Page Templates），已经在2002年发布了。
• 提供一个组件模型，让定制产品更容易。意思就是说，要把产品功能分解成更精练的、可以单独升级的零部件。
• 用一些像传统model-view-controller (MVC)或是文档视图（document-view）的架构，让呈现与业务逻辑完全的分离。

Python就是Zope的"秘密武器"。Zope正与市场上的众多基于Java的方案在竞争。为什么相比于基于Java的应用服务器，用Zope开发应用更具生产力？主要原因就是因为我们有Python。尽管有上面的这些吹捧（牛B），然而对于Python程序员来说，Zope并没有太多的吸引力。（说的的确是实情。Jim还是有自知之明的。译注） 为了让Zope对Python程序员产生更大的魅惑，为了让我们更好的撬动Python的力量，这就是我们开发Zope3的最大的原因所在。

接下来的历史

在经历了几次头脑风暴之后不久（或许与之并无关联），Zope公司雇佣了核心的Python开发团队，Python Labs，他们带来了新的敏锐的洞察力。（请读者们回想一下Guido是什么时候在Zope公司呆过？）

正如上面提到的，那些头脑风暴的一个早期成果就是ZPT了。它让开发者和（网页）设计者的协同工作成为了可能。

我们意识到，一个类MVC的framework是需要一个组件架构的，于是我们研究了一下，它（的功能之一）应该支持业务逻辑和呈现的分离。

在一个无状态的环境比如HTTP里面，使用组件架构是一个大的挑战。在无状态环境下，每一次request所需要的组件都要被装配，这意味着组件装配必须要很容易的就能进行。

请注意CMF也提供了一些组件系统的特点。业务代码已经被从内容对象中分离了，并且分成了tools和skins。Tools是提供特定业务功能的组件。 Skins是提供呈现和业务分离的，重点在呈现上。虽然CMF能满足我们的一些需求，并且也示范了把业务逻辑和呈现从数据管理中分离的一些好处，但是我们还想看看，我们能不能把事情做得更好。具体的来讲，我们想要用对象来扩展功能，而不是用一个个的模板和脚本。CMF依赖获取机制（acquisition），这意味着所有的模板和脚本都共享着一个共同的命名空间（namespace），而不管内容的类型是什么。名字最好要包含类型信息，并且要小心谨慎的取（要不然就可能重名）。

我们考虑了一个初步的组件分类，分成内容，视图和业务组件，大至对应着MVC。还设计了一个通过注册和横切（traversal）组件的方法来进行组件装配的机制（component-assembly mechanism）。组件装配基于对象的连结，通过接口（interfaces）。

在2001年将要结束的时候，我们在tutorial中不断的重申，明确要从事的Zope3项目要达到下面这些目标：

• 改善开发体验，提供一个更合理的开发模式，吸引Python和其它的开发者
• 让在Zope中创建有用的对象更简单
  • o让使用现存的Python类成为可能（作最少的或者不作修改） o要使用Zope的功能，只要作少量的额外改变
• 让学习曲线变得平滑
• 让软件重用更加便利
  • o 使用已存在的非Zope特色的对象 o 增加、删除、替换现有对象的功能 o 改变现有对象的用户接口 o 提供可替换的访问对象的方式（比如FTP，XML-RPC,wxWindows）
• 配置Zope软件更灵活
• 借鉴那些从使用、开发Zope2积累的经验教训
• 把CMF的技术和开发模式整合到Zope中去

Zope3最初是作为Zope2的一个分支开始的。我们很快意识到，已有Zope2代码的桎梏让人很难爆出新思想的火花。向后兼容老的代码，让人分心不少。最后我们决定，在一开始不考虑向后兼容的问题，很快地我们就为Zope3建立了一个独立的开发树。

开放的进程

在2001年12月，在开放Zope仓库来捐献给Zope公司外部的过程中，我们对Zope社区公开了Zope3项目。Zope3提供了一个重大的机会，让人人能参与到Zope的过程中来。我们推广了sprint，在Fredericksburg举行了三次python sprints，分别在2002年的一月和二月。

• 使人们加入到Zope3的开发中来
• 建设这个社区；还有
• 完成重要的工作

sprint活动最重要的好处是让人们能碰个面，互相认识，还有相互合作。这让后来的远程工作变得更容易了。

Zope3项目也导致了为Zope工作的人数大量增长。主要的和大多数的代码都来自Zope公司之外的贡献。Zope3是个名副其实的社区项目。

发现之旅

从Zope3项目宣布到现在，已经整整3年了，这比预期的长了许多。大多数功能是在第一年开发出来的，那时进展神速，并且是在没有任何Zope2代码的基础上，只是从一个广阔的社区中得来的。在2002年底，我们开发出了我们认为应该是第一个alpha版的release。

在2003年初，我们进行了一连串的"geddons"，这是一个为了及时的在夏天完成Zope3所进行的重构工作。这是评估我们工作成果的一段时期。然而基于我们的经验，我们发现原始设计方面需要修改。到2003年的秋天，我们已经作了许多重大的改进，但是又确信还有许多修改要做，一直要进行到2004 年。

从2003年初到2004年是一个巩固基石的时期。只增加了为数不多的新功能。工作重心几乎全部放在建造一个可供日后增添功能的稳固的基石上。大致可以描述为--简化框架！后期增加的代码大部分又去掉了。

许多修改是十分有意义的。举例来说，我们停止使用上下文包装（context wrappers）来指明对象的位置（location），换为了直接保存位置路径，这使得位置感知（location-aware）和对象引用的代码被大大简化了。我们完全重写了大部分的子系统，这些修改极大的完善了最终系统的结构。这些是可行的，因为我们希望花些时间，来从最初的失误和重做工作中得到一些教训。

作出要慢下来并且要从容不迫、花费双倍的时间来做出第一个发行版的决定，是基于我们要求卓越的承诺，还有，意识到了我们不必那么操之过急。因为不管怎么样，Zope2还是一个优秀的系统，它还有很长的生命周期呢。

在Zope3的工作中，我们的开发流程也改进了。我们做到了:

• 养成了测试的习惯
• 养成了一个优秀的文化：为了让事情做到最好试着把步伐慢下来，如果有必有情愿把工作重新来过;还有
• 创立了一个新的方法来试着把文档和测试结合起来，这很快成了一个非常积极的习惯。

X3.0的发布

到2004年初，已经有了好几个使用Zope3的产品了。很明显的，Zope3已经为产品应用作好了准备，虽然还缺乏几个功能或者还没有准备好要发布。一些本可以在产品中很技巧性的使用Zope3的人，不愿在他们所需要的功能没有稳定之前冒险这样做。我们决定缩小第一个release的目标，只包含那些已经稳定的基本功能，能让那些不需要传统的通过web在线开发（through-the-web development）功能的人开始使用Zope3。我们给Zope X3.0定位于开发人员发行版，只包含那些从2004年初夏起就已经稳定的功能。

Five项目

最近有个开发项目Five(http://codespeak.net/z3/five/)，可以在Zope2中使用Zope3的组件架构，来提供部分的Zope3的功能。

现在的Zope3还不向后兼容Zope2，虽然有Five项目的一些努力，但是许多Zope3的功能都不能用于Zope2.

现在的Zope3是给Python开发者们用的。还没有对web在线开发的功能提供稳定的支持，尽管已经有了简单的试验版。我觉得一段时间之后就不成问题了。

有许多Zope3的第三方产品，部分已经在Zope2中成熟稳定了，象cataloging，已经包含于Zope3中了。

基于上面这些有限的信息，Zope3给你展现了一些显著的优势：

• 它提供了一个非常清晰的开发模式。试用过Zope3的开发者们都会发现它是一个比Zope2更具生产力的开发环境
• Zope 3更容易适应特殊的业务需求。有趣的是Zope3应用再也不像传统的Zope应用了。举例来说，一个应用不再需要使用传统的"对象文件"模式，Zope3让那些使用关系数据库的应用变得简单得多
• Zope3被设计为从底层支持I18n 和 L10n应用
• Zope3提供了很好的文档：一本书（还在不断增加中），一个教程，一个内嵌的Api参考手册，和一个在不断细化的内部开发文档。

你该使用Zope3吗？

Zope 3 既有重大的改进，也有相对于Zope2的局限性。是否需要使用它依赖于你的实际情况。幸运的是你不必马上转换到Zope3上面。Zope2还将伴随我们相当长的时间。实际上，Zope2可以让我们从容不迫的对待Zope3。要感谢Five项目，你可以在Zope2的应用里面使用部分的Zope3技术。随着时间的过去，Zope2也会具有更多的Zope3特性，让最后转变到Zope3的结局更简单更容易。