Dick McCarrick
内容开发人员, IBM
2005 年 7 月 18 日

要了解 IBM Workplace Designer，还有比和构建它的那些人直接交谈更好的办法吗？在这次访谈中，我们访问了 IBM Workplace Designer 团队的三位成员，讨论了 IBM Workplace Designer 的主要特性和未来的发展。

下载 IBM Workplace Designer！ 参阅该页，并按照相关说明下载 IBM Workplace Designer 的预览版本。

IBM Workplace Designer 是一种基于 Eclipse 的开发工具，可使用它为 IBM Workplace Collaboration Services 和 IBM Workplace 产品家族的其他成员开发应用程序。要了解关于 IBM Workplace Designer 的更多信息，请参阅 IBM Workplace 应用程序开发页面。该页中可以找到最新的文章、视频、手册和其他帮助您入门的信息资源的链接。也可以查看随产品一起提供的 IBM Workplace Designer 在线帮助。本文发表的时候，IBM Workplace Designer 也计划在短期内发布。

这次访谈中，我们访问了设计和构建 IBM Workplace Designer 的团队中的三位成员。

请介绍一下您在 IBM Workplace Designer 团队中的角色。
Maureen Leland：我是负责 Workplace Designer 团队的主管。我负责全部的用户界面：表单和控件、视图，等等。我的团队在这方面做了大量工作。我认为我把 Domino Designer 的思路也带到了这个产品中，我担任 Domino Designer 的项目主管有将近五年的时间了。

David Taeib：我是 Workplace Designer 脚本部分、连接 Eclipse 和 Workplace Managed Client 的底层基础设施这方面的团队主管。我在 IBM 工作了九年半，大部分时间作为开发人员从事一个称为 Domino Global Workbench 的项目。最近几年，我发现了 Eclipse 很有潜力，于是我改变了我的职业生涯。我非常高兴地看到 Workplace Designer 将以 Eclipse 为基础，因为这种搭配太完美了。对我来说，Workplace Designer、类似 Domino Designer 的产品概念和建立在 Eclipse 上的 UI 简直是最佳搭配。

Philippe Riand：我是 Workplace Designer 的架构师。我的职责是推动规范的开发和保证实现中遵循这些规范。我很早就开始使用 Java 平台，我认为我是最早使用 JDK 1.0 的开发人员之一。我还开发过很多 Notes 应用程序，Workplace Designer 让我非常兴奋，因为它为 J2EE 表格引入了与 Domino 相同的概念。

请简单地谈一谈，Workplace Designer 是什么和能够用来做什么。
Maureen： 可以建造由表单组成的 Workplace 组件。它让开发人员用他们已经习惯的结构建造 Workplace 组件。您不用管 J2EE，也不必担心服务器、beans、JSP 页面这些麻烦的东西。脑子里想着“有一个表单，有按钮，还有编辑框。我可以为它们编写脚本”就可以了。这是一种基于表单的脚本工具，与开发人员熟悉的 Domino Designer 一样，因此可以充分利用原来的技能来创建 Workplace 组件。

但它不完全是 Domino —— 如果不知道 Domino 也没有关系。Visual Basic 用户也会对这个环境感到满意的。

Philippe：我想再延伸一下，我们希望引入 Domino 社区已经熟悉的那些概念，给他们留下好印象。不过我们也希望吸引 Java 开发人员，因为目前实际上唯一的选择就是基于 J2EE，非常复杂。有些任务，比如部署，用 J2EE 不容易做。因此，我们希望帮助 Java 开发人员上一个台阶，让他们把精力从底层代码转移到业务应用程序和业务代码上。所以说，Workplace Designer 提供了这个世界上目前还没有的一些东西。

David：我想再接着 Phil 的话说下去。我想，这里的关键词是生产率。如何保持 J2EE 的强大功能，同时又消除它的复杂性，用一种非常快速的开发方式来提高生产率？Domino 开发人员知道怎么做到这一点。他们在开发环境中创建应用程序后，不需要多少修改就能测试应用程序。然后可以再回来，添加新的字段，从美观的角度进行调整，然后重新测试。因此对于 Workplace Designer，我们尝试引入这些特性为 Eclipse 平台实现部署和测试的自动化，这些改进可以简化您的工作，大量细节的自动化可以提高您的生产力，否则就要自己手工做。我认为，这是 J2EE 世界的一大胜利，像编写部署描述文件和测试这类一般任务可能要花很多时间，并且很单调乏味。

Workplace Designer 在哪些方面可以与 Domino Designer 比较？两种产品的区别又在哪里？
Maureen：看到 Workplace Designer 时，您会发现一个看起来非常熟悉的环境，但是并不相同，有些明显的改进。适当的地方做了一些调整，在左侧可以看到设计组件。设计组件和在 Domino Designer 中设计的数据库或模板并排在一起。展开之后，它们与 Domino Designer 的书签模式非常类似。里面有表单、设计元素列表，还有脚本库。

Maureen Leland

区别之一是 Workplace Designer 有模式，而 Domino 有共享字段。处理数据的方式有很大差别，坦白地说，我认为这也是令 Domino 用户非常满意的地方，因为 Domino 最棒的一点就是很容易处理数据，但是，便于处理数据也是 Domino 最不好的地方！在 Domino 中处理数据很容易，但是一旦数据放到那儿后就很难在应用程序中管理数据。比方说，您可以使用共享字段，而共享字段实际上只是一种很大的、纯文本的模式。在 Workplace Designer 中，我们把模式正式作为表示数据的一种方式。经过一段时间后，我们希望把 Workplace Designer 做得与 Domino 一样容易使用，同时又保持控制数据结构的能力。如果数据是层次化的，那么可以建立层次模式，按照这种方式来使用。Workplace Designer 非常强大并且可控制，我们正努力让它和 Domino 一样容易使用。

另一个相似的地方是编程面板。虽然看起来很相像，但是感谢 David，我们能够利用 Eclipse 的脚本编辑功能并且真的做到了 —— 我不想剽窃 David 的杰作，但这一点的确很棒（大笑）。编程面板中包含您需要的一切。

Philippe：Domino 是基于文档的。在 Workplace Designer 中，我们使用了 XML，这是用于在不同端口间发送数据的一种众所周知的文档格式。这一点非常重要，因为目前 Domino 开发人员转向 J2EE 或者这个平台时，他们面临着自己不熟悉的对象编程模型。他们必须使用类，必须和 EJB 打交道，必须应付这类东西。要解决的第二个问题是脚本。不一定要创建 Java 类，也能在 Workplace Designer 做一些编码（虽然需要的话也能做到）。我们也让 JavaScript 解释器提供了一些相关的 @function。

David：最主要的是我们保留了 Domino 中最好的地方，在某些方面又作了改进，特别是标准的使用。我们从一开始就把 Workplace Designer 作为工业标准来做。我们使用了 XML，使用了 XPath，还大量使用了 CSS。通过引入这些标准化成分，我们实际上是为了使它更容易和那些已有的工具交互。工业标准、质量标准和 W3C 提出的那些标准，所有这些形形色色的标准就是当今游戏的主题。如果想获得成功，就必须是开放的、可以互操作的。

Philippe：您可能需要从合作伙伴那里弄回一些文档，在 Workplace Designer 中处理后再发送出去。这就需要一种公共格式。这就是为什么标准重要的原因。

David：标准非常重要，我相信这会造成很大的区别。我们希望能够与其他那些大型平台一争高下。我们希望最终保证大门对所有类型的标准都是打开的。

第二点就是将 Domino 最好的地方引入 Workplace Designer，比如简单操作的概念。我们喜欢这些特性，并把它们保留在了 Workplace Designer 中，虽然在第一个版本中还很有限。我们希望继续保留简单操作这个概念，因为它能够迅速地完成任务。更进一步地说，我们希望方便您构造代码，并将其绑定到简单操作，您完全可以将其作为插件，这个概念来自 Eclipse。这样就使 Workplace Designer 具有很强的可扩展性，这一点非常重要。

我们的很多听众都具有 Domino 背景。他们已经完成的代码在多大程度上可以不需要重新编码就能在 Workplace Designer 环境中使用呢？
Philippe：谈到利用已有的资产，可以分为两个方面。其一是利用关于该平台已有的技能和知识，其二是利用您用这些技能构建的那些东西。因此，我们首先要做的是尽可能利用用户的技能。我们已经谈到，我们把很多 Domino Designer 概念引入了 Workplace Designer。这样有助于马上利用您现有的技能。

Philippe Riand

利用已有资产的第二个方面是，如果需要或者有理由将应用程序从 Notes/Domino 转移到该平台。我们提供了一个导入工具，但是设计这个工具的目的不是为了这样迁移应用程序，比方说“啊，我用 Notes 做了一个应用程序，在 Designer 中也来一个吧。按一下按钮就搞定了。”这并非我们的目标。导入工具的目的是让您快速开始新的 Workplace 应用程序，但不是一对一的迁移。经验证明，如果要从 Notes 迁移到另一个平台，利用目标平台的新功能实现一对一的转移更有效。因此，我们让人们使用已有的 Notes 表单开始创建 Designer 应用程序。

David：Phil 所说的导入特性，目标仅仅是应用程序自身的设计，不包括数据。这个工具是很全面的。当然，不可能得到百分之百的设计，除非特别简单，否则这是不可能的。我们这样做的目的是为您开个头，帮助您在 Workplace 世界中快速启动应用程序开发。在这个版本中，从 Domino 导入的机制就是这样。在以后的版本中，我们将根据用户的反馈意见寻找一些改进方法。

Maureen：可以考虑把数据从 Domino 导入 Workplace，但是也可以与 Domino 共享数据，只要让 Workplace Designer 组件和 Notes 应用程序操纵同样的数据就可以了。因此未来的另一个目标是能够处理 Notes 数据。我认为这个目标极其重要，有利于增强互操作性，因为可以建立独立的 Notes 客户机处理装满数据的数据库，客户机也可以建立在 Workplace 客户机甚至其他客户机中。

David：Notes/Domino 7 的一个新特性是允许 Notes 访问 DB2 数据。这也看作是 Notes 和 Workplace 的结合点，因为现在两个平台使用同一个后端系统。

Domino 程序员还会在 Workplace Designer 中发现哪些吃惊或者不熟悉的地方？
Maureen：首先，他们在寻找视图设计元素的时候会发现找不到这些元素了。视图在 Workplace Designer 中不再是设计元素。Workplace Designer 中有少量控件封装了可视化的查询，这些控件实际上就是视图 —— 在 Domino 中，视图就是一组选择公式再加上公式的可视化。在 Workplace Designer 中，我们建立了将其分离开来的架构。第一个版本中，我们没有时间将其彻底分开，因此它们看起来仍然紧密联系在一起。但是最终我们将建立表示选择公式的查询设计元素，并且可以将它们用于不同的可视化，这些控件的其中之一是表格形式的视图控件。因此，在寻找一般的视图设计元素时，必须到表单中去找 —— 基本上所有的视图现在都内嵌在表单中，但是，我们已经建立了获得选择公式供以后进行可视化的架构。这是 Workplace Designer 与 Domino 的一个很大不同。

Philippe：我们对模式使用了 XML，据我所知，Domino 设计人员可能对此还不熟悉。因此一开始可能有些迷惑，因为 Domino 的工作方式是创建字段 —— 多个字段。他们在这方面必须转变观念，因为有多个文档，这种转变不会自动完成，要利用这种能力必须采用稍微不同的思维方式。此外，Domino 开发人员习惯于计算字段，需要计算字段的时候，就将该计算字段放到文档中，这样就可以了。使用 Workplace Designer 的方法有点不同。

David：Domino Designer 有一件事情不能做，就是保存带有错误脚本的表单。我们现在允许这样做了。（笑声）我相信这一点将大受欢迎。在 Workplace Designer 中允许保存任何东西，即使有错误。我们也会将其集中到一个专门的选项卡中，在这里可以看到所有表单中包含的全部脚本错误。双击一下就会自动打开表单并转到包含错误的脚本片段中。您可以方便地管理脚本中的所有错误，这一点是从 Eclipse 借鉴而来的。还有一点不同就是图片。不能将图片嵌在文本中，也不能直接向文档中添加图片了。必须首先将图片引入到组件中，而这些图片是可以共享的。与 Domino 中一样，我们也有图片设计元素。

Maureen：这样做的优点是，您可以说“好，我们要开始更新了。要怎么处理它？”应用程序中的所有图片都是可以控制的资源。

David：另一个区别是 Workplace Designer 选项板，而 Domino 中没有这些选项卡。您可以拖放控件。我们有大量的拖放控件。在 Domino Designer 中，您把鼠标放到表单中，然后说“文件，创建字段”。现在我们将字段的概念分离成了多个控件，这些控件都放在了选项板中，您可以看到很多控件：编辑框、按钮……它们都是单独的。而在 Domino 中，您需要添加一个字段，然后选择类型。

David Taieb

我们提供了一个丰富的环境，允许拖放操作。在选项板中可以看到当前上下文允许使用的所有组件，您可以选择、拖动、放到表单中的任何位置。

Philippe：Domino 和 Workplace Designer 有一个很大的区别，在 Domino 中设计表单时涉及的不仅是 UI，还包括来自文档实现的大量数据。在 Workplace Designer 中，这些概念被分开了。但是我们知道 Domino 的使用方式很受欢迎，也确实很棒。因此，您可以获得与 Domino 相同的用户体验，但是现在这些概念分开了，一切都自动化了。您可以按照“Domino 方式”开发表单，也可用另一种方式，比方说设计自己的模式或者从第三方厂商那里获得模式，然后将 UI 添加到模块上。这两种方法都能用。

Workplace Designer 支持什么样的脚本语言？
David：目前，可以编写业务逻辑的主要脚本语言是 JavaScript。因此我们在运行时中提供了 JavaScript 解释器，用来编写业务逻辑。我们为这个引擎添加了一组 @functions，它们看起来类似于 Domino，用户可以使用和 Domino Designer 中相同的方法。环境自身使用 Content Assist，它允许您随时中断调用某种帮助器，告诉您如何完成当前正在查找的关键字。比方说输入 @ 符号和 Ctrl-Space，就会自动弹出一个列出所有可用的 @function 的窗口。这一点同样可以提高生产率。

UI 的左侧是上下文引用选项卡，列出了所有的对象 —— 可以随时使用的全局对象。因此，它与上下文是密切联系的。对于用户来说，以这种方式使用 JavaScript 是一种非凡的体验。

我们还支持脚本库（借自 Domino）的概念，您可以将诸如 JavaScript 函数之类的代码片段封装到设计元素中，需要的时候，可以通过导入来调用它们。使用“导入”，然后继续后面的操作。一旦启用导入，就可以看到所有能用的脚本库，左侧的引用选项卡显示了所有可用的函数和全局对象。不用说“脚本库里放了什么东西？”它就在那儿。使用 control 键把鼠标悬停在 import 语句上，这样做还可以直接跳转到脚本库，单击一下鼠标马上就可以打开脚本库来查看。

Philippe：我们提供了 Java API 的一组 JavaScript 包装程序，使这些 API 访问起来更容易一些。我们还提供了一组非常容易访问的库，只要调用一个函数即可。传递 XML 文档或者 XML 文档副本的方式是 XPath 的基础。因此，XPath 和 Workplace Designer 完全集成在一起，可以混合使用 JavaScript 和 XPath。只需要查询文档就可以在 JavaScript 中执行 XPath。

David：我们有非常完善的 XPath 编辑器，包括帮助器和相关的便利设施，那些不了解 XPath 的人也很容易编写。

Workplace Designer 提供了什么样的部署特性?
Maureen：部署非常容易。我们提供了应用程序的迭代测试，部署和迭代开发。简而言之，首先要填写一个部署配置文件。然后设计将会保存在设计机器上的本地文件系统中，最后必须将这些文件移到服务器上。可能是同一台机器（对于这个预览版本通常就是您自己的机器），也可能是共享的部门服务器或者测试服务器。因此要建立部署配置文件，它会提出一些问题，如服务器的名称、服务器用户名和口令以及使用什么数据库，如 Cloudscape、DB2 等等。只要建立了这个文件，右击您的组件然后说“部署”，“轰”地一声就完成了。如果希望将编辑字段改成黄色，然后看看效果如何，只要重新部署一次在浏览器中查看就行了。非常快捷。

这是对测试阶段而言的。如果准备发布，可以将应用程序导出到 WAR 文件，然后让管理员把它放在真正的产品服务器上。

David：所有这些特性产品中都有。有一个菜单，按照菜单作就是了。简直天衣无缝。

Philippe：我们知道 J2EE 部署一般来说比较痛苦，就像 Maureen 所说的，我们提供了两个方面。一是在服务器上的 WAR 部署，二是创建数据库。一切都是自动完成的，对 J2EE 开发人员来说就像梦幻一般。如果您是管理员，希望更多地控制服务器上产生的结果和执行的任务，您可以按照服务器标准 J2EE 部署提供数据库和 Web 应用程序。但这样做并不是必需的，您可以选择最简单的方式。

David：第一次部署组件时可能要花几分钟，但以后就易如反掌，只要几秒钟就行了。这一点对提高生产率至关重要。

Workplace Designer 和 Workplace Builder 之间的关系如何？
Maureen：Workplace Designer 建造 Workplace 组件，Workplace Builder 把这些组件安排到页面上，这是一种协作关系。

David：与 Workplace Designer 相比，Workplace Builder 是一种高端工具，因为 Workplace Builder 没有深入涉及到 Workplace 组件的内容。Workplace Builder 允许参数化所谓的“可变点”（points of variability），我相信熟悉 Workplace Builder 的人都知道。但是 Workplace Designer 允许您生成这种可变性，然后供 Workplace Builder 使用参数化组件的实例。

有一点我们还没有说，那就是组件脚本。这些脚本可以在 Workplace 组件的事件生命周期中添加业务逻辑。Workplace Builder 定义了组件的生命周期。创建组件的实例时，有大量的事件被触发，如创建实例、删除实例和添加成员。我们允许 Workplace Designer 向这些事件中放入脚本，添加程序性的逻辑，供 Workplace Builder 消费。它就相当于 —— Maureen，如果不对的话请说出来 —— 相当于 Domino 中的数据库脚本……

Maureen：是的。

David：……打开和关闭数据库时会触发少量的脚本。可以认为它类似于 Domino Designer。

您认为 Workplace Designer 将来的版本会做哪些改进？
Philippe：我们将改进运行库。目前的运行库对 Workplace Designer 用户是隐藏的，但是前面已经谈到，我们确实希望这个平台尽可能地开放，能够与 Rational 共享某些产品。因此，Workplace Designer 的下一代运行库将以 JSF 为基础。我将在 JSF 之上增加某种，比方说，框架，让脚本中的 Java 执行服务器的脚本任务。显然，这支持 JavaScript，并且支持的语言超过了 15 种。第三方可以提供自己的脚本语言。

David：我们正考虑增加工作流。另外还有图表 —— PI、图形。所有这些都将成为组件中的设计元素。允许业务伙伴创建自己的设计元素类型也非常有意义。非常、非常强大。

Philippe：新的 JSF 运行时还将提供易于理解的组件模型，您可以很快地在表单中引入自己的组件，不一定要作为 Java 开发人员开发组件。找一些材料，再添加一些，组件就完成了。

Maureen：因此我们把一切都看作有助于组件化和共享的资源。对我们的设计而言，这一点很重要。

David：调试。Domino Designer 的第一个版本中有一个调试器文件，它不是产品的正式组成部分，而是作为技术预览包含进来的。这个特性将在下一版本中完全实现。调试非常重要，我们计划围绕着调试增加尽可能多的功能。

Philippe：目前我还不能确定，但是我们准备支持 Portal 开发。我们准备与即将发布的 Rational Application Developer 7.0 保持同步，它将为 Workplace Designer 提供一些插件。这与我一开始提到的事情有关，我们希望提供有助于提高生产率的高层次概念来吸引 Java 社区。为此，他们可以使用 Workplace Designer。当然，开发人员也不一定要使用 Rational，这只是一种选择。

David：再次强调，我们将普遍使用 Eclipse 插件来完成这些任务。我们将能够使用 Rational Application Developer 7.0，并充分利用它的特性。

还希望对 Workplace Designer 读者补充什么吗？
Maureen：它是世界上最棒的产品！