第十六章-Five和Zope3.docVIP

Five和Zope3 使用Archetypes，我们知道如何为Plone编写一个基本的内容插件产品。 这一章将讲述如何通过Five插件在Zope2中使用Zope3技术，进行可重用的、可扩展的、组件化开发，也为产品的未来向Zope3升级之路做好铺垫。 这是文件系统上的扩展产品开发，因此这一章是面向扩展开发人员而编写的。 本章学习重点是: 理解Zope3相对于传统的Zope2开发带来的优势，以及Five在引入Zope3技术中所起的作用 掌握一些Zope3的核心技术： 接口、适配器、视图、事件 理解自动测试对于提升软件品质所起的作用，掌握测试的方法 16.1???Zope3开发新概念 这一节讲述从Zope2到Zope3的进化过程，Zope2开发所形成的固有的缺点在Zope3中是如何被克服， 并介绍了Five作为一个Zope2产品为了引进Zope3的先进技术而扩展了哪些功能。 还有Zope3中广泛使用的配置语言ZCML，同样在Five中应用广泛。 Zope3所带来的其实是一场关于如何写作可扩展产品的方式的变更， 因此这一章的重点是介绍Zope3所带来的软件设计观念上的革新。 16.1.1???Zope3是什么 Zope3就是第三代的Zope，Zope3采用了最新的设计模式和组件架构，是对Zope2的一个完全重新改写。 传统的Zope2发展到现在，已经暴露出了很多问题： 为了尽可能简单的提供丰富的功能（特别是对于非技术用户而言），Zope做了许多自动化的工作。 这对于简单的应用是非常好的，但是对于那些更复杂些的应用，反而是一种障碍了。 如隐式获取(Implict Acquisition)。 Plone的皮肤功能继承自CMF，它依赖获取机制， 这意味着所有的模板和脚本都共享着一个共同的命名空间（namespace）， 而不管内容的类型是什么。名字最好要包含类型信息， 并且要小心谨慎的获取（否则就可能重名）。 还有Zope提供了非常方便地安装第三方产品（products）的机制。 但是它很难适用于所有的产品。 在传统的Zope产品中，一个对象的所有功能都是它自己的类或者基类提供的。 改变这些产品行为的唯一方式，是去修改或者子类化它们。 修改产品通常会使维护升级变得很困难。 子类化也是令人讨厌的，因为它会让基类和子类之间耦合性得过于紧密了。 Zope3以组件架构的方式来解决了这些问题， 对于Zope2中那些易混淆的概念则予以剔除或改造， 如Zope3去掉了隐式获取的支持，只允许显式的获取。 组件装配基于对象的连结，通过接口（interfaces）对组件进行组装。 并且使用视图将业务逻辑与呈现相分离。 在Zope3中每一个页面模板可以声明为只用于某一种接口， 只有那些实现了这个接口的对象才能使用这个页面模板， 这样页面模板的名字就不再是全局的了，因此很好地解决了命名冲突的问题。 但是目前的Plone2.5以及即将发行的Plone3.0都是运行于Zope2的， 因为它仍然依赖于Zope2的隐式获取机制。 对于一个很容易定制开发的Plone而言，隐式获取机制并非全无用处， Plone中有一些关键的特性还得依赖于它。 只是Zope2中缺少一些Zope3所拥有的新的特性， 如全局模板命名冲突等问题， 因此需要一种简单的方案在Zope2引入Zope3的解决方式。 16.1.2???Five是什么 Five (主页在 /z3/five/) 是一个Zope2上的产品， 它的出现正是为了解决Zope2向Zope3的过渡之路。 它帮助开发者一步步从Zope2走向Zope3的组件架构。 不使用它，Zope2和Zope3会是两个完全分离的世界，并且不可能在它们之间进行移植。 Five的目标就是让Zope 2的开发人员在Zope 2中使用Zope 3的代码。 使用Five产品，允许在Zope2中使用Zope3的接口、适配器和事件机制。 注意Five和Zope3已经被包含在了从Zope2.8开始的最近的Zope发行中， 如Zope2.8(其中内含Five1.2版)和Zope2.9(其中内含Five1.3版)， 还有Zope2.10版本(其中内含Five1.5版)。 它位于Zope-2.X/lib/python/Products/Five，因此这些Zope版本不需要再安装一次Five产品。 如果说Zope-2.8中只是简单地包含了Five和Zope3产品， 至Zope-2.9中，Zope的内核已经是使用Five和Zope3技术改写过的了， 主要体现在其中的接口定义等已经改写为了Zope3接口的形式。 现在使用的Plone-2.5的主要运行平台是Zope-2.9， 其中也是大量使用了Five以运用Zope3的设计模式。 至Zope-2.10，这是一个Zope3的主要技术都融