在WebDu会议期间，我们有幸采访了Adobe公司从事Web工具开发的高级工程师Greg Rewis，他向我们介绍了他们设计的中心产品Ajax框架项目Spry。
什么是Spry?为什么说它是独一无二的？
为了更好地理解Spry的特性，我们首先需要理解传统Ajax应用开发中的传统，也可以说是挑战。
Ajax不是什么新出现的东西，它已经流行很长时间。它只是把存在相当长时间的现有技术整合起来。但是现在是以一种新的方式实现，任何Ajax应用的首要问题是应用者本身，你可以有两种选择，或者完全从头开始开发，没有人乐意这种方法，或者选择一个框架。

目前，网络市场中存在大量的框架可供我们选择，从我们Adobe公司角度来说我们解决的问题是所有框架都需要JavaScirpt开发人员，并且他的JavaScript编程技术确实达到标准。

在此之上，你还必须对XML以及整个浏览器工作的后端方式等有深入的了解，不用说90年代的Web设计开发人才，即使是今天，我也不可能达到开发一个好的Ajax应用所需要的技能水平，因此这种方法是不切实际的。

因此我们想到“我们能提供些什么帮助呢”，所以我们开发了Spry框架，该框架和其它框架一样都是十分基础的，我用一个可能不太好理解的话来说，一个框架就是已经写好的JavaScript脚本的集合。

我们开发的Spry框架，即设计者眼中的javascript集合，为了更简单的应用，我们将它作为labs.adobe.com的一部分提供给社区，令人惊喜的是，它获得了大家的广泛欢迎，下载量一路攀升。

应用Spry的过程是否变得更简单了?

哦，是的，使用过程肯定变得更简单。当我们提出这个问题时，让我们借用美国的一句谚语，向墙面投掷一个东西，看看是否能够粘在墙上，结果肯定是粘住并产生共振，我们已经和社区结合在一起。是的我们承认，到目前为止实施Spry框架的过程仍旧是一个手工编码的过程。

现在你可以从labs.adobe.com下载得到这个框架，其中包括JavaScripts、指南、示例文件等等可供我们用来结构该框架。但是实际的实现仍是一个基于文本的过程。现在很明显，我们希望大家利用Dreamweaver来实施。不过，因为该框架实际上不过是一系列JavaScripts集合，所以你可以使用Notepad或任何可以编辑HTML的工具来实施这个框架。

为了使得这个过程对用户来说更方便，更简单我们将它作为Dreamweaver CS3的一部分，这将使得所有操作都是可视化的。因此高效开发基于Ajax的应用即将真正实现。

为什么Spry仍旧作为一个框架提供给大家？

是的，我们公司内部一个主要的考虑因素是“好，我们该如何确切的看待该产品，它是一个产品吗？它不是一个产品吗？它是产品的一部分吗？”。从一个软件开发人员的角度考虑，如果我们将它与Dreamweaver合为一体使得只能通过Dreamweaver获得，那么我们该如何更新呢？基本上，我们就被锁定在Dreamweaver的生命周期之内。

因此，我们采取了另外一种方法，我们说“你知道我们将此作为一个独立的开发包”，用于Dreamweaver的整个Ajax Spry框架实际上不过是一组告诉Dreamweaver如何处理的JavaScript文件和XML文件集。

对我们来说，这将意味着在Dreamweaver下一个版本的整个生命周期中，我们可以一个完全独立的路径继续开发Spry。因此，你可能会见到 Spry 2.0或3.0以及其它的插件，到时所有Dreamweaver用户都可以从网站下载。通过下载你将获得所有的新插件，新效果或者任何提供的东西。


为什么你会选择使用Google的代码用作XML解析器而不是自己开发？

好的，Ajax的一个主要方面就是XML连接，构建一个Ajax应用是完全可能的，而且目前我们也见到了许多这样的应用，常听到人们说“哦，这是一个Ajax应用”。并不是因为数据真是静态的，才将它编码成HTML页。对于一个真正的Ajax应用，实际上加载和处理的是XML。

所以这就是我们遇到的问题，如何解析XML？当然我们可以自己进行开发，但是，既然Google已经投入了大量资金进行XML的理解与解析工作，我们为什么还要在重复开发呢？因此我们决定让我使用它们的成果作为我们的XML解析器。

Spry可用于为Apollo构建Ajax应用吗？

当然可以，我想在新闻发布会上宣布Apollo时可能让大家产生一个误解，那就是人们都认为“哦，Apollo是一个新的Flash播放器。”然而，Apollo绝不仅仅是一种播放Flash内容的新方式，因为它拥有显示HTML，JavaScript脚本等其它功能。

因此，Apollo应用程序有相当大一部分是完全应用Ajax和Spry框架开发的。

Spry更符合标准吗？

是的，最近我在范库弗峰出席一个会议，有机会发表了社区内的一些标准化问题，刚好就讨论到这个主题，更有趣的是大家提出的这些标准建议可以用到很多已经出现的框架。

我们采取的方法是，认真权衡每种可能方法的利弊，然后再去进行实际开发。有人说“你们本该应用类属性”，是的，但是有多少设计人员考虑类这个概念呢？

我认为类是和我们的CSS相关的，通过它引入其它的一些东西。我对我们的设计人员真的很困惑。因此在方法选择上是以设计者为中心的。我认为标准很好，我也完全赞成标准而且在Adobe公司我们深信标准的重要性。然而，有时为了使某些东西更容易实现，我们不得不做出一些折衷。

因此我们尽力做的就是找到一个较好的平衡点，做出适当的折衷。这就会对部分人适用，而对另一部分人不适用。我想这可能就是软件开发中的原始本质吧。

在新的CS3套装发布之后，我们会看到有更多的网站使用Spry吗？

是的,我们的确希望如此，但是作为一名技术人员我的格言是就是因为你不想那样做，你就应该那样做。我们已经看到Spry的一些应用。美国广播公司NBC就在它们的网站中使用了Spry，如果你去NBC.com去看一下就会发现上面的网页中有一部分是单独更新的，那就是用Spry开发的。现在我们正看到大量的组织机构使用Spry。

但是很显然，在CS3发布之后，我想我们将会看到更多使用Spry的生动案例。

影音源文件地址：http://www.tudou.com/v/rZzckDyQptI

影音源文件地址：http://www.youtube.com/v/muibPAUvOXk

Zope是什么？
作者：潘俊勇 
Zope: 一个开源的web应用服务器
又一个开源Web应用服务器如果你是一个Python语言的爱好者，那你应该知道Zope这个Python上的杀手级软件；如果你阅读过Eric Raymond的著名的开源启蒙文章《魔法大熔炉》，那你应该知道Zope这个经典的开源商业化案例；如果已经厌倦了J2EE的繁琐，或者Ruby On Rails的过于简单，那么，Zope应该是值得你关注的另外一个选择了。

Zope( http://zope.org )是一个开放源代码的web应用服务器。2002年，Zope被Linux Journal评为最佳的web应用服务器；2004年，Zope成为冠群CA公司宣布其开放源代码战略后的首批资助项目；Zope拥有美国海军、北约组织、美洲银行、波士顿在线、法国10多个政府部门、摩托罗拉、SGI等众多的重量级用户。

使用Zope，可快速构建功能强大、可扩展的web应用。典型的，比如内容管理、内部网、电子商务、门户，甚至ERP应用。其中，世界级的内容管理系统Plone便是基于Zope构建。Zope上有丰富的第三方产品插件供选用。

脚本开发快速构建应用1996年，当时是Zope公司CTO和 Python领袖的Jim Fulton，为教授CGI程序起草讲稿。Jim针对这门课程，以他自己的方式研究了所有关于CGI方面的现存文档。在讲课返回的途中，Jim开始思考传统的CGI的编程环境中他不喜欢的方面，包括：脆弱、缺乏面向对象和暴露Web服务器细节等。从这些最初的沉思开始，在返回的飞机中Jim写出了Zope 的核心内容。

一般企业IT部门的技术人员，通常很难完全掌握复杂的可重用组件开发技术，比如J2EE/.NET。而Zope最初的目标，就是针对这些懂得基本编程技能的开发人员，也就是Web脚本开发人员。Zope服务器提供了一个Web开发界面，开发人员可简单地创建各种脚本对象，便可构建出所需要的web应用。这个过程，避免了耗时的编译过程，也没有复杂的配置文件，更不需要用户掌握类、重载、继承之类的任何概念。完成脚本后，马上就可以测试看到结果。对脚本开发人员的支持，是Zope最重要的特性之一。

Zope脚本开发技术和原理Zope 上主要的脚本开发对象包括Script (Python)、ZPT(Zope Page Template)、DTML、Z SQL Method，他们分别负责逻辑代码、HTML/XML页面展现、非HTML的内容生成、关系数据库SQL操作。其中，ZPT类似JSP/PHP/ASP 语言。

Zope 所有的脚本对象，以及其他的内容、工具对象，都保存在一个叫做ZODB的对象数据库中。ZODB实现了对象的透明存取，开发人员不必关心对象的存取细节，避免传统关系数据库中的O/R映射这一环节，大大简化了开发过程；ZODB支持事务处理，能够用于企业关键应用；ZODB支持自动的对象缓存管理，能够调节和优化性能；最重要的，ZODB支持ZEO(Z Enterprise Object)，可将对象分布在多个Zope实例上并行运行并保持同步，这使得Zope能够支持多机负载均衡，可平滑扩展，用于大型的应用。同时， Zope也提供了一组关系数据库适配器工具和SQL脚本对象，脚本开发人员使用他们，也能够轻松构建传统的关系数据库应用。

所有的对象都保存在ZODB中，Zope负责对这些对象的发布。事实上，ZOPE就是“Z对象发布环境”的简写(Z Object Publishing Environment)。用户可通过http、ftp、xml-rpc或webdav等途径访问ZODB中的对象。Zope首先将各种请求统一封装为一个 REQUEST对象，然后根据请求的URL路径在树状结构的ZODB中逐个访问各个对象，最终定位到目标对象。这个过程叫做对象的漫游（Traverse）。找到目标对象后，Zope将请求中的参数解析、预处理、传递到对象的默认方法中并执行，最后将执行结果返回到最终用户。这个过程中，Zope可负责从 URL到对象方法执行的整个过程，而脚本开发人员仅仅需要构建和拼装各个脚本对象。

整个对象发布过程，都是受Zope内置的权限控制保护的，未经授权的用户不能访问到对象，或者不能执行发布方法。Zope的管理界面中，管理人员能够成组管理用户和分配权限，控制对象的访问和方法的执行，或者委托他人进行网站局部区域的管理。脚本开发人员基本不必在代码中编写的权限控制逻辑，只需由管理和集成人员使用Zope配置管理界面设置完成。

如何和现有系统的用户帐号进行集成登录认证，是企业部署常见的问题。Zope有可插拔的用户认证和管理机制(acl_users)，安装相关插件产品并设置完成后，可通过LDAP接口和Windows的活动目录实现集成(LDAPUserFolder)，也可直接利用现有关系数据库中的用户帐号信息进行登录认证。

扩展开发和Zope3脚本开发适合针对具体应用的开发；如果需要构建Zope上可重用、可再发布的软件，可在文件系统上开发插件产品(Products)。插件产品的开发，需要掌握更多的开发技能，面向的是组件化的扩展开发人员，可满足十分复杂开发需要。

Zope 目前包括Zope2和Zope3两个分支版本. Zope2基于传统的对象继承技术，目前已经十分稳定，特性丰富，Plone等大型应用均基于Zope2开发完成。Zope 2对脚本开放人员非常友好，但是对于扩展插件产品开发人员，却并不友好。Zope 2使用了大量的类继承，对象的耦合性非常高，接口文档也不全。这使得Zope 2形如巨兽，难以驾驭，Zope 2的扩展开发学习曲线相对比较陡。

针对了Zope2的开发经验和教训,Zope3则是采用最新的设计模式和组件架构技术，对Zope2的一个重写。在Zope3中，组件之间通过配置文件（ZCML），按照接口适配拼装，组装成应用。Zope3采用类似J2EE的对象松耦合架构，同时具备 Python的简洁性和优美性。Zope 3上已经发展了很多项目，最典型的一个是ubuntu Linux的发行管理平台lauchpad(launchpad.ubuntu.com). Zope 3对扩展开发人员更加友好，对传统的Zope 2脚本开发支持也正在逐步加强和完善。

从Zope 2.8开始，Zope 2引入了一个叫做Five的插件产品，可在Zope2中可以使用Zope3的大部分技术。从Zope 2.9开始，Zope的很多内部核心组件，已经替换为Zope3的新代码。Zope 2逐步成为Zope 3的一个特殊定制版本，Zope2到Zope3正走向一条平滑过渡的路线。

Zope主要使用Python语言编写，在关系系统性能方面的模块则使用C语言编写，可在Windows、Linux、Unix、Mac OS等多种平台上安装运行。特别是在Windows平台上拥有傻瓜化的安装包，用户上手试用非常方便。

Zope的中文化目前已经有完整的解决方案，中文Zope用户组(www.czug.org)是国内最专业的Zope技术社区。