临发布 2.0 前对 ExtJS 作者 Jack Slocum 的访谈

  • Scott Delap
  • Frank Cheung

2007 年 10 月 11 日

话题:JavaWeb框架语言 & 开发

在 Ext 下一个版本的预览文章发布近一个月之后,ExtJS 团队最近发布了该框架的2.0 alpha 版本 ,包含以下新功能:

  • 可编组和摘要的表格
  • 可滚动的 Tabs
  • 固定布局
  • 包含列的 Tree 器件
  • Web 桌面
  • 新 API 文档中心
  • 一些新演示

需要指出的是,ExtJS2.0 的 API 已经被数个客户投入到产品开发的环境中,并已经是稳定的 API。框架遵从 LGPL3.0 的协议,也提供商业和 OEM 的许可。2.0 最终完成时间大约定在十月底。

InfoQ 特约了 ExtJS 的作者 Jack Slocum 就这次发布进行了访谈:

解析一下 ExtJS 与 JavaScript 生态系统下 JQuery、Dojo、Prototype、YUI 等之间的关系。是不是打算构建一个多层的 JavaScript 的框架?还有,为什么我们需要结合以上的库,而不是单纯使用 ExtJS(虽然可以单用)?

JQuery、Prototype 和 YUI 都属于非常核心的 JS 库。虽然 YUI,还有最近的 JQuery,都给自己构建了一系列的 UI 器件(Widget),不过却没有一个真正的整合好的和完整的程序开发平台。哪怕是这些低层的核心库已经非常不错了,但当投入到真正的开发环境中,依然需要开发者做大量的工作去完善很多缺失之处。而 Ext 就是要填补这些缺口。主流开源框架中只有 Dojo 像 Ext 一样,尝试着提供整合的开发平台。相比 Dojo 这个出色的工具包,我们认为 Ext 能提供一个粘合度更高的应用程序框架。Ext 的各个组件在设计之时就要求和其它 Ext 组件组合一起工作是无缝合作的。这种流畅的互通性,离不开一个紧密合作的团队,还必须时刻强调设计和开发这两方面目标上的统一,而这点是很多开源项目未能做到的。从构建每一个组件开始,我们始终都强调组件的外观、性能、互通性和可扩展性,而我们认为组件已经达到了这几点的要求。

Ext 绝对可以单独使用。实际上,除了有特定的要求,推荐单独使用 Ext,这样的话文件占位更小,支持和整合也更紧密。我们也支持与 jQuery、YUI 或 Prototype 整合使用,作为低层库的角色出现,以提供处理各种核心的服务,如 DOM 和事件处理,Ajax 连接和动画特效。使用整合方式的一个原因是它们已具备了一些特定的器件而 Ext 并没有原生支持——像 YUI 的 History 控件便是一个典型的例子。这时,Ext 需要依赖 YUI 这个库的底层来实现 History 控件,这样一来的话也可免去 Ext 自身底层库,从而减少了整个程序的内存占用。另一个使用整合方式的原因是,对于许多已在使用其他底层库的程序,你可能希望逐步加入 Ext。总之,如果已经有了其他库,Ext 可已利用它们。我们的宗旨是为用户提供各种可能性和性能上的优化。而事实是,只要实现了相对应的底层库接口,为任意一个框架添加上适配器是没有问题的——人们可以轻松地将 Dojo、Moo、Ajax.NET,或其它 JS 库转变为 Ext 的底层。 

要支持这些不同种类的 JS 库,最困难的事情是什么?

最大的挑战也是最明显的,就是保持 Ext 与其它库的同步更新,并要保证能良好地配合工作。每当其中的一个库发布了新版,我们必须测试它们,看看有没有哪些变动会导致 Ext 出现问题。

要支持各种不同的 Web 浏览器,同样,遇到最大的问题是怎样的?

我们所面对的最大的问题,就是对修改和新增内容的测试和验证花去了大量的时间。不但要处理各浏览器以及版本上的差异,还要对付各浏览器不同文档类型声明(Doc types)之间差异。

可以让我们放心的是,我们直接在 Ext 中内建了很多工具,让它处理跨浏览器的问题。包括针对 Box 模型问题常规化的一个基类组件,特定平台的常量值和一些自适应的 CSS 样式类,这些样式类可解决浏览器怪癖(Browser Quirks)的问题而无须 CSS Hacks。 正因为有了这样的内建支持,再加上核心框架是稳定和久经测试的,用户一般不需要过多考虑跨浏览器的问题,从而加快开发速度,并且大大减少应用所需的测试量。

如果有一种鞭策 EXT 2.0 前进的动力,你能形容下那是什么吗?

为开发者带来坚实和协调的基础平台。尽管 1.x 版本的 EXT 已经不错了,但是在某些方面仍有余地可以降低开发者的门槛,并减少代码量。特别在创建复杂程序的时候,我们希望 API 本身能应付此类较复杂的处理:例如组件的延时渲染、组件的生命周期等任务可以交给 API 控制,省下开发者手工操作的步骤。关于 2.0 的另外一个主要改进是一个更加健壮的基础平台,满足了定制组件(插件)、群组组件(容器)和组件初始化的要求。在布局和组件的一致性方面的新改进,意味着一旦你明白了怎么配置好一个 EXT 的组件,你便能够以相同的方式处理框架内全部其他的组件。最终为用户带来更快速更易用的开发,而没有牺牲 EXT 本身的体积和性能。

这次 2.0 的升级你认为最具创新是什么?  

应该说是容器的新架构。在 1.x 中,程序布局主要是围绕 BorderLayout(针对布局)和 BasicDialog(针对窗口和对话框)。虽然这两个组件表现不错也非常好用,。但是若想在其基础上复用代码,扩展新功能,就受到很多制肘。在 2.0 里,我们使用新容器和布局架构,增加了相当数量的布局管理器 (CardLayout、ColumnLayout、FormLayout、TableLayout 等共九个),并重新整理了容器 API,使得你能以相同的方式将组件加入到 TabPanel、Window、Panel 等等。总之,我们提供的不只是 UI 器件,还是一整套运行良好的框架,一个可帮助用户生成应用程序的基础。

你会如何比较用 ExtJS 和 JavaScript 与其它技术,如 Silverlight 和 Flex 来实现客户端应用?

从某种方面来说,Ext 实际会是这些以浏览器插件为基础的新技术的一种补充。Flex 和 Silverlight 都可以包含 DHTML/Ajax。我们其中的一个Adobe AIR Simple Tasks演示正是 Ext 在这种环境下运行的一个好例子。从这个例子,可以看出在 EXT 的帮助下实现的高质量外观,原生 AIR 不花费大量时间来包装 UI 器件和定制 CSS 难以达到这种程度。

当然,原生的平台拥有一些原生的优势,当前 JavaScript 没有本地编译和合适工具的支持。JavaScript 应用程序更简单的开发和部署模型也自有其存在的空间。Microsoft 推出的《Sliverlight 企业部署指南(Enterprise Sliverlight Deployment Guide)》,当中有 SMS、活动目录(Active Directory)等等一大堆令人头痛的东西——这些都是 JavaScript 应用中绝不会见到的!另外,新近问世的移动平台(如 iPhone)上的 JavaScript/DHTML 支持却有明显的改进(比插件支持更受欢迎)。看起来还是有很好的理由去选择 JavaScript,而不是那些基于插件的技术。

可供选择的工具很多,最重要的是开发者应该针对手头的工作选择最适合的工具。有时候基于插件的技术才是最适合的,但我们很自信 JavaScript 技术还会在很长的一段时间里占据 Web 开发的一席之地,而 Ext 会在其中扮演重要的角色。

ExtJS 下一步的计划是什么?

当前的重点是发布一个稳定和可靠的 2.0。尽管首次发布的是一个 Alpha 的版本,但是由于 2.0 的代码库已经被不少开发者实践使用过,所以我们相信这是一个不错的开始。
查看英文原文:ExtJS Creator Jack Slocum Discusses Upcoming 2.0 Release
译者简介:Frank Cheung 有多年 Web 前端开发经验,动态语言爱好者。负责 EXT 中文站(www.ajaxjs.com)JavaScript 开源论坛 Js 堂(jstang.5d6d.com)的维护工作。专注 Ajax 和 WebUI, 从 YUI-Ext 起,翻译了不少 EXT 相关的资料(发布在 Javaeye AJAX 论坛、和自己的博客上www.ajaxjs.com/frank)。
JavaWeb框架语言 & 开发