Dojo Toolkit 创始人 Alex Russell 在 2006 年 10 月的一篇 eWeek.com 文章中这样评论 Dojo，“就像 Web 开发人员的毒品……像毒品一样，只要您开始每天使用它，就不会再回头。”作为项目的创始人，他可能对自己创造的东西夸张了些，但当项目中的主要贡献者谈起它来都眉飞色舞甚至有些敬畏，而且同时非常乐意指出项目的局限性、下一步工作、困难以及面临的挑战，这就是另外一回事了。

来自 IBM® 的几位 Dojo 主要贡献者最近聚到了一起，讨论 Dojo 已完成的工作、目前的现状以及未来的发展方向。他们还将给出关于特定项目区域的细节的看法，并讨论在进行很少会面的开源项目时所面临的挑战。您可以通过以下内容了解他们的看法。

警告：他们的热情让人上瘾！

Dojo Toolkit 是什么？

Dojo 是一个开源 DHTML 工具包，其项目于 2004 年启动，并于此后成了使用非常广泛的工具包。项目的总体目标很简单：制作非常可靠的工具，能“在动态 Web 应用程序开发领域得到广泛采用”。Dojo 是一个雄心勃勃的项目。如果您访问该项目的网站，将会找到大量描述实际上可帮助形成良好习惯的 Dojo 功能。例如，在 Dojo Widget Library（称为 Dijit）的介绍中，有这样的文字：

该工具包的网站指出，到 2007 年 4 月，预发布版本 0.4x 的下载量已经超过了 300,000。仅 2007 年 11 月，当月刚发布的工具的 1.0.0 和 1.0.1 两个版本的下载量就有大约 40,000。（1.0.x 的这些下载量数据摘自该网站发布的统计数据。）

Dojo 项目得到了很好的资金支持，这对实现其宏伟的目标起到了很大的促进作用。此工具包是 Dojo Foundation 所赞助的三个项目之一，而此基金得到了 IBM、BEA、Sun™、AOL 和其他企业的大力支持。如果继续得到资金投入，不断发展的 Dojo 将会存在一段相当长的时间。

回页首

参与人员

Becky Gibson 是 IBM 的马萨诸塞 Westford 实验室的高级技术人员，而且是 IBM Emerging Technologies Group 的成员。她于 2006 年 5 月开始进行此工具包的相关工作，为工具包的 0.4、0.9、1.0、1.0.1 版作出了很大贡献。Becky 在 IBM 担任 Web 可访问性架构师。她在 Dojo 项目中的工作重点是可访问性。

Jared Jurkiewicz 是 IBM 位于北卡罗莱纳州 Research Triangle Park 的一名软件工程师。2006 年，他在进行 IBM WebSphere Application Server Web 2.0 Feature Pack 的相关工作时开始使用此工具包，并于 2007 年初开始进行 Dojo 的相关工作。他参与了 0.4、0.9 和 1.0 版的工作。

Adam Peller 是 IBM 的一位软件工程师，在波士顿郊区的家中工作。他于 2006 年 4 月开始进行此工具包的相关工作，参与了从 0.3 版开始的所有版本的工作。他是 IBM Emerging Technologies Group 的成员，目前是 dojoX 项目的临时项目负责人。他是负责为 IBM 进行 Dojo 和其他 Ajax 框架的首次评估团队成员。

回页首

讨论

WebSphere 开发者技术期刊（WebSphere Developer Technical Journal，WDTJ）：Jared，您在 Dojo Toolkit 项目中进行了哪些工作？

Jared Jurkiewicz：我主要进行 Dojo Toolkit 的 dojo.data 部分的工作，努力促进 API 的可重用性。我们已经完成了 1.0 版本的 API 的主要部分，不过当然还需要进行更多工作。我还处理在各个约定（如我们谈到的 AjaxWorld）中的表示形式。目前，我是 Dojo 的 dojo.data 模块的主要人员。另外，我还进行 dojox.wire 模块的工作，并进行各种错误修复。

WDTJ：是否完全可以假定大部分开发人员都将从 Dojo 0.4x 过渡到 1.0？

Jared：但愿如此！实际上，我认为有些人将会选择新版本，有些则不会。1.0 与 0.4.X 在某些方面有巨大的差别。拥有自定义小部件的用户会发现过渡需要进行大量的工作。而刚刚使用 Dojo 小部件的用户可能会发现过渡相对较为简单。这完全取决于用户的应用程序的情况以及是否需要进行更改。甚至在 Dojo 的邮件列表和论坛上仍然出现了很多 0.4.X 的问题。

WDTJ：过渡到 Dojo 1.0 后，Dojo 0.4 开发人员将会在新的基于 1.0 的应用程序中实现哪些好处？从 0.9 过渡到 1.0 呢？其主要优势是什么？

Jared：1.0 要快得多。页面解析和呈现时间得到了极大提高。以前有四种方式在标记中声明小部件，但现在只有一种方式。另外，还删除了很多并不能真正提供帮助的“小魔术”，因为您最终必须知道其进行的工作。dojo.io.bind 就是其中之一：在 0.4.X 中，将其用于隐藏基础 I/O 机制（xhr、脚本等），但实际却不能达到所需的效果。各自都需要特殊参数，因此只能更为清楚地将其作为独立 API 使用，并且更易于理解。此外，1.0 在小部件的可访问性和国际化甚至 BiDi 支持方面都进行了大量的工作。虽然此工作目前尚未完全完成，但要比 0.4.X（更不用说目前已有的其他 JavaScript™ 工具包）好得多。

WDTJ：Jared，前面您提到 dojo.data 的工作已经停止了。数据管理对任何编程语言都非常关键。为什么会放慢这方面的工作？对哪些组件更为关注，为什么？

Jared：实际上，过去曾停止 dojo.data 方面的工作，但现在已经恢复了。在 0.4.X 中，我认为可能出于多个原因而暂缓了 dojo.data 工作。1) 坦白说，开发足够灵活的 API 来处理多个服务类型、处理浏览器 I/O 的异步行为而且要易于使用，这个任务相当困难。2) 其他工作的优先级更高。社区中的每个人都要承担 Dojo 之外的全职工作，实际上，大部分公司由于到了年底产品交付和项目完成其工作量都会增加。因此，为了完成自己雇主的项目，大家必须减少在 Dojo 方面的工作量。3) 这个模块不像 Dojo 中的其他模块一样“有趣”。编写小部件很有意思，您能立即找到满足感。数据访问 API 并不提供这种即时的反馈。换句话说，它是基础设施。因此，对于大多数 Web 开发人员而言，这种满足感才是 Web 编程的最大乐趣所在。这个解释并不一定对，但确实如此。不过幸运的是，这个时期已经过去了！对于 Dojo 0.9 和 1.0，dojo.data 工作进展相当不错，随着 1.0 版使用的增加，越来越多的人开始加入这方面的工作。我现在非常期待下一年社区能作出更大的贡献。

WDTJ：对于 1.0，您预计会在 dojo.data 方面有哪些改进？

Jared：如果有时间，我们将推出其他 API，如 Schema API 之类，如果库中声明实现这些 API，就可以通过其获取关于其中包含的数据结构的信息（属性和类型）。而且，更多的单元测试、更多库等都将得到改善。唯一需要的就是找时间进行相关工作。

WDTJ：最近在 dojotoolkit.org 上发布的文章中，您指出“Dojo Toolkit 依赖于其贡献者的努力工作，我们始终希望能够有更多的人加入这个行列。”我们好奇的是，有多少人参与 dojo.data 工作，或者仅仅修复相关的工作？

Jared：开始的时候加入我们工作的人并没有预期的多。幸运的是，这种情况已经得到了改进。Brian Skinner 在很长一段时间内都是我们的主要贡献者，但最近已经减少了这边的工作量，将重点放在其他事情上。他的工作得到了大家的广为赞许。后来，我们已经有另外两个人接替他的工作。最近有人将两个新的库作为补丁发布，不过这两个库并不完整，缺乏单元测试，因此这些代码尚不能包括在工具包中。再稍微投入一点工作，这些代码就有希望加入其中。另一个贡献者提交的补丁未包括贡献者许可协议（Contributors License Agreement，CLA），因此当然不能加入其中。除了个人贡献的内容外，我们最近还得到了一份企业贡献的内容（SnapLogic 的开发人员编写的数据代码库），目前正在等待审查。其目的是为了提高 Dojo 与其数据服务的集成。不过，我希望有更多的人参与文档工作。这个部分一直是（现在仍然是）最难获得贡献的领域。不过，这不足为奇，因为开发人员天生就讨厌编写文档。我在这方面做得也不好，因此这也是我需要加以改进的一个领域。对于希望为 Dojo 作出贡献的人（dojo.data 或其他部分），我鼓励您这样做！请填写 CLA 并将其发送到社区，从而加入我们。

WDTJ：Adam，您在进行 Dojo Toolkit 项目的哪些工作？

Adam Peller：作为 IBM 最早参与此项目的委员之一，我一直作为 IBM 和 Dojo 社区之间的联系人，负责将 IBM 的需求传递给 Dojo 社区，并努力帮助将关于 Dojo 的信息反馈给 IBM。我从 Chris Mitchell、Doug Hays 和 Jared 等人那里得到了关于这方面的很多帮助。从一开始，我的重点就是为 Dojo 构建国际化框架——这对 IBM 非常重要，而且我认为之前没有哪个 JavaScript 框架真正尝试去解决这个问题。我之所以加入此项目，是因为我看到 Ajax/DHTML 中的 i18n 支持很差，而不是因为我认为自己是这方面的专家。从这方面而言，我实际上充当的是 IBM 的 i18n 专家的代理人。我还参与到了很多“核心”模块和工具问题中，而且最近在 Dijit 项目方面的涉足更深了一些，因此我自己接触了大量代码，但这是个大项目，我仍然发现很多部分我并不太了解。我还不时地涉及构建和项目管理问题。实际上我会参与可以促进项目进展的任何事。过去这几年能在开源领域“玩游戏”，这种感觉非常棒，看到这么多人使用 Dojo（特别是 IBM 内部），我非常高兴。

Jared 所说的关于 1.0 版的话都非常中肯。总的说来，我认为 1.0 版利用了通过 0.4 版和之前版本中的错误得到的经验教训。我们现在将以前三种方式改为了一种，并对 API 进行了合并，尝试使用一致的风格，且减少了一些华而不实的东西，我们避免了不必要的工作，如错误检查，或对已经存在的 API（例如 dojo.dom）进行包装。有时候会因为功能开销过大，或者因为不够重要而让用户投入运行时开销或加入代码库。减少代码有很多好处，包括性能（连接所涉及的代码量对于脚本而言非常值得考虑），但也会减少我们以往的交织依赖关系。

WDTJ：在 Dojo Core 论坛最近发表的帖子中，有人提出了这样的问题：“为什么在 dojo.js.uncompressed.js 中有这样的代码行：var d = dojo;”。您的回答是“只是为了每次在给定代码块中使用‘dojo’时少用三个字节。”Dojo 核心开发人员是否有可以遵循的风格指南？性能和可读性之间的折衷是否在开发人员中进行了讨论？

Adam：我们有 Dojo 风格指南，但大部分讨论的是排版格式（空格等）、一些命名和结构等。其规定可能不如所期待的那样全面，但在 OSS 社区中，我们有时候在执行已有的规范时仍然会遇到麻烦！通常认为在 Dojo 中代码量是第一位的。具体的测定方法存在很大差别，而且在表述方面存在一定的自由度。代码中有 d=dojo 的开发人员可能是为了编写最为简洁的代码，有时候可能阅读有一定的困难，但却充分利用了每个字节。越接近核心部分，这种方式越容易被接受。另外，某些模式可以归结到遵循 Dojo 使用的压缩模式方面。

WDTJ：Adam，我认为双向语言支持是 IBM 产品的一项需求。BiDi 工作在 Dojo 1.0 中是不是已经完成了？

Adam：BiDi 尚未完成。我们的目标是预计在 2008 年第一季度推出的 1.1 版中完成此工作，但目前由于 IBM Shanghai GCoC 实验室的帮助，我们已经在超过 75% 的 Dijit 代码中实现了 BiDi。Dojo 手册中有关于 BiDi 状态的文档，另外在 trac 中也能搜索 BiDi 相关的信息。

WDTJ：Becky，您在 Dojo Toolkit 项目开发中担任什么角色？

Becky Gibson：我的工作重点是核心小部件集的可访问性。我在 Web 可访问性领域工作了多年，其中包括在 Accessible Rich Internet Applications (ARIA) 规范方面的工作。我们使用 ARIA 技术来向视力较弱、仅能使用键盘和辅助技术的用户提供核心小部件集的完全访问功能。我们在 IE 和 Firefox 中支持视力较弱和仅能使用键盘的用户，并使用 JAWS 和 Windows-Eyes 屏幕阅读器支持在 Firefox 中使用屏幕阅读器。Dojo 是第一个能够为其核心小部件集提供可访问性的开源工具包。

WDTJ：JAWS 是什么？

Becky：JAWS 是在美国使用最广泛的屏幕阅读器，包含数百个用于导航和获取信息的命令。越新的版本包括的复杂脚本支持越多。JAWS 和 Window-Eyes 屏幕阅读器都能通过进行额外的工作来很好地支持 ARIA。

WDTJ：IBM 非常关注可访问性，对吗？

Becky：可访问性对 IBM 非常重要，因此很多 IBM 产品团队都在考虑使用 Dojo，因为我们需要提供可访问性。我非常高兴地宣布，Dojo Core Widget Set 已经通过了 IBM 的 CI-162 Web Accessibility Checklist 认证。网格小部件尚未包含在 1.0 中，但将在 1.1 版中优先考虑。另外，仍然要进行额外的工作来提高 1.1 版中核心小部件的可访问性。ARIA 规范已经快要完成了，将会在 Firefox 3 中完全实现。这将会提高布局容器和一些更为复杂的小部件（如组合框和富文本编辑器）的可访问性。

WDTJ：其他还有哪些人也参与了可访问性工作？

Becky：可访问性是通过可访问性专家团队实现的。其中包括来自多伦多大学 Adaptive Technology Research Centre 的 Simon Bates 和 David Bolter，他们一直在参与此项目的工作，并担任 Dojo 的委员。他们在 Dojo 可访问性方面的工作得到了 IBM 和 Mozilla Foundation 的资金支持。IBM 的 Pete Brunet 也在进行 Dojo 可访问性方面的工作。除了实际在小部件中实现完全可访问性，我们还帮助对 Dojo 社区就可访问性问题进行培训。Dojo 社区非常支持可访问性，帮助修复了相关错误并创建主题来支持可访问性。

WDTJ：在开源项目中工作有什么感觉？

Becky：我必须承认，我是花了一点时间才适应开源社区的工作方式。人们在 #dojo IRC 频道“闲逛”，回答问题和彼此提供帮助。我花了一段时间才学会了如何与里面的人们相处，同时获得了修改 Dojo 代码的自信。Dojo 的所有人员都非常支持，但能够面对面地交流确实很有帮助。幸运的是，我有机会在 Dojo Developer Days 与大家见面。

WDTJ：Becky，您能介绍一下核心小部件集采用的 ARIA 技术吗？可访问性工作的内部情况可能很多读者都不了解。

Becky：ARIA 定义要添加到 DHTML 控件中的角色和状态元数据。此信息由浏览器（目前只有 Firefox）进行解释，通过平台可访问性 API 向辅助技术提供。对于 Windows®，此 API 即 MSAA (Microsoft Active Accessibility)。辅助技术将随后向用户表述信息。例如，树形控件没有本机 HTML 元素，因此必须通过脚本进行创建。Dojo 小部件的角色和状态包括在 Dojo 模板中，会在创建小部件时动态地分配。对于树的情况，整个树容器被给予树的角色，树中的每个项目被给予树项目的角色。如果树节点是可展开的，则将会获得“expanded”状态。如果节点在创建时折叠，expanded 值将为 false，而在展开的情况下该值将为 true。除了在创建时分配角色和状态外，状态必须在控件发生更改时进行更新。对于树项目的情况，如果节点展开，则必须将状态设置为 true，而在折叠时必须将值更新为 false。

与 Dijit 树控件交互的屏幕阅读器用户将会听到关于获得焦点的树项目信息、其在树形层次结构中的级别，其展开/折叠状态以及子项目的数量（如果有）。树形控件通过箭头键导航——就像 Windows 文件管理器中的树形控件。以前树形控件是通过清单和链接创建的，因此用户必须使用制表键跳到每个树项目。在 Dijit 树中，用户使用右箭头键展开树项目、左箭头键折叠树项目，然后使用上下箭头在树项目之间移动。

Dijit 系统中存在用于通过脚本设置角色和状态的特定 API：setWaiRole、getWaiRole、setWaiState、getWaiState 等。在 Dojo 1.0 中，角色和相应的状态都已经添加到所有核心小部件 (Dijit)。

WDTJ：Becky，您说“ARIA 规范已经快要完成了，将会在 Firefox 3 中完全实现。”那么 IE 呢？我们开发人员都喜欢 Firefox，但我们的产品（至少在 IBM 是如此）也需要在 IE 上工作。

Becky：问题是 IE 尚不支持 ARIA。这需要浏览器部分进行相应的工作来支持 ARIA。正如上面指出的，浏览器必须解释额外的角色和状态信息，并通过可访问性 API 将其提供给辅助技术。IBM 鼓励 Microsoft 将 ARIA 支持添加到 IE，我们希望 Firefox 提供的支持和 ARIA 在商用产品中的实现将帮助推动问题的解决。好消息是，JAWS 屏幕阅读器（一款更受欢迎的 Windows 屏幕阅读器）已经过更新，能够更好地支持 Firefox 和 ARIA。Opera 浏览器也支持 ARIA 和全键盘可访问性。

WDTJ：Jared 认识到了需要文档的辅助。这是否在国际化和可访问性方面也是一个问题？

Adam：我不能代表 Becky 的意见，但这些领域的编码工作似乎正在有序地进行。文档工作在那之后有一些改观，但直到最近，我们这些开发人员的工作重点实际上都在编写代码上。有时候会出现需要撰写文档的情况（这始终是大家认为的第一大麻烦），我们会停下编码工作若干周，进行文档撰写工作。不幸的是，这通常会失败。最近，一些相当不错的文档编写人员加入我们的项目，他们积极主动地参与文档的结构规划、撰写和编辑工作，以保持文档的一致性和可读性。开发人员积极地参与其中，但其流程是由真正了解文档的人执行，这使一切大为改观。我真的非常满意新的在线手册“Dojo Book”。不过，我们一直都在寻求反馈信息——可以直接在每页上留下评论——和志愿者来帮助进行此工作。不过，仍然需要进行大量与文档相关的工具方面的工作。我们的 API 文档方面的工作力度仍然不够，这对我们的用户是个极大的问题。

关于国际化，我们在 Dojo 和 Dijit 代码库中的工作进行得相当顺利。剩下的 BiDi 问题应该在下一个发布周期中得到解决。正如我提到的，我从 IBM Shanghai GcoC 得到了很多帮助。DojoX 并没有相同的 i18n 需求，但我希望我们最终能将其提高到相同的标准，支持其他 i18n 功能，例如经常讨论的非公历日历；我认为，在这方面我们需要更多的帮助。本地化流程——通常涉及到翻译工作——以两种方式进行。对于这方面最初的工作，我们要感谢 IBM Web Feature Pack 2.0 团队在翻译方面提供的资助，并采用 IBM 的标准对其进行了严格的测试。这些翻译（我想其中涉及了 12 种语言）全部作为开源贡献内容返回 Dojo。此外，我们还有个人贡献者提供自己语言的翻译。我们非常欢迎这种帮助。

Becky：由于我们在 Dojo 中使用的 ARIA 技术非常新，因此并没有太多的现成文档可以依赖或参考。我对 0.4 手册进行了首期工作（针对 0.9/1.0 进行更新）。a11y 团队在每个小部件的文档中创建了可访问性特定部分。正如 Adam 所说的，团队中有具有文档和写作技巧的人加入来改进文档及其组织，这真的很棒。

WDTJ：开源流程非常有意思，但可能很多读者并不能很好地理解。例如，谁决定什么代码进入工具包？

Adam：通常要得到全体 Dojo 贡献者的一致同意。各个模块有自己的所有者，他们是对每个项目具有否决权限的“仁慈的独裁者”。

Becky：您达到委员级别时，可以在不经过审查的情况下签入代码，并在其他人签署了 CLA 的情况下对其代码进行签入处理。但是，如果您对构建造成了负面影响，效率低下或只是有些笨拙，您都会被社区点名，因此您需要确保知道自己在做什么！可以通过 Internet 中继聊天（Internet Relay Chat，IRC）（或者在必要的情况下通过电子邮件）询问不同领域的专家。Dojo 贡献者邮件列表用于在进行大规模更改前讨论新想法、问题和建议。就像任何开发项目一样，人们必须对代码的质量负责，并在必要的时候进行审核。

WDTJ：您喜欢开源虚拟环境吗？

Adam：除了认识真正出色的人才外，在 Dojo 中工作最有意思的部分就是完全的在线开发社区的文化。大量沟通工作都是通过 IRC 进行的，除了偶尔的社交会面外，虽然您可能整天都与其他人一起工作，但您并不会实际与他们交谈。尽管会议在 IRC 中进行，但这需要一段时间才能适应，但我认为这目前是我最喜欢的会议类型。我认为，这样所交换的准确信息要多得多，一旦克服了最初信息过载的感觉，就会惊奇地发现自己在各方面都有所提高！与通常的一言堂方式不同，有时候我们感觉像每个人都能够同时提出自己的想法，而且都能够为大家所了解。另外，与真的分布在世界各地的团队一起工作充满了乐趣，您可以在将问题保留到欧洲大陆第二天的早晨之前与亚洲的朋友先交流一下——不过这对睡眠习惯有些影响。

WDTJ：你们如何确定最后期限或里程碑？由委员会决定？

Adam：需要大家一致同意。我们通常并不会太早进行事先计划。因为很难这样做，因为很多委员都是兼职或志愿者。我们通常将精力重点放在一个版本上，并同时对之前的错误修复版本进行维护。有时候，我们会实际会面进行现实性核实，并对长期计划和目标进行更新，我们会尽力每年安排一次或两次会面，讨论此类事项。

Becky：最后期限和里程碑似乎是通过“集体智慧”确定的，通常以 IRC 中的对话、每周例会以及 Alex Russell 和项目负责人的输入和指导等形式出现。这并不意味着最终期限和里程碑的确定是随机的，这个过程中进行了大量的考虑和计划，最终期限将被认真对待（尽管并不是总能达到最终期限的要求）。 这是 IRC 会议的好处之一，任何人都可以发言，所有评论都向所有人显示。

WDTJ：感谢各位接受采访！

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文
  
  
• Dojo Toolkit
  
  
• Dojo 小部件库
  
  
• Dojo 的历史
  
  
• Dojo 下载统计数据
  
  
• Dojo Foundation
  
  
• Using the Dojo Toolkit with WebSphere Portal
  
  

关于作者

Scott Johnson 已从事了 24 年软件开发工作。他于 2000 年加入 IBM Research Triangle Park Lab，担任 WebSphere Application Server JSP 处理程序的团队负责人兼架构师达六年之久。Scott 目前是 IBM 在 JSR 245 (JavaServer Pages 2.1) 专家组的代表。

为本文评分

评论

回页首

内容

• Dojo Toolkit 是什么？
• 参与人员
• 讨论
• 参考资料
• 关于作者
• 建议