走近ExtJs之关于作者Jack的十个问题（更新）

这是去年10月份的文章，不经不觉，YUI-EXT/ExtJS已经走过一年多的时间，让我们在2.0正式版临发布之前，重温一下Jack Slocum的其人其事和EXT最初的端倪：


Q:您是怎么进入前端工程（Front-End engineering）这一行的?
从1995年起，我开始接触WEB开发。那时我主要做的是建公司网站。后来我也参与了一些较有璩头的网站的网站，如compare.net (现在的 shopping.msn.com), howardstern.com 和drlaura.com.

Q:什么使得你选择YUI来做扩展？
有四到五年的时间我只用在IE上做开发。但随着FIREFOX等浏览器日渐流行，我们迫切需要一个能够跨浏览器的解决方案。YUI正好可以帮到我轻松地过渡此类问题。随着开发的不断了解，我发现有几种办法，让我可以改进、或者说扩展原YUI的功能。今年的八月份，我建立了关于YUI的BLOG并且开始 YUI-EXT的开发。

Q:项目YUI-EXT的真正目标是什么？
创建一个对象可再用的库和小器件(widgets)，来改进整个YUI可用性，使得YUI不需要其它库的帮忙。


Q:目前你写了那些组件？
（译注，这是去年10月份的文章，组件当时到现在的情况可能有较大的变化。请参阅相关已更新的讯息）
A Grid component that supports various data sources, paging, inline editing and various selection models.
A flexible SplitBar component.
A basic TabPanel component.
A basic Toolbar component.
An extended Animation library built on top of YAHOO.util.Anim that supports automatic animation sequencing and synchronization.
A variety of utility classes that make every day development with YUI a little easier:
Element:  Simplifies working with DOM elements. It also supports performing YUI animations automatically when setting an element’s properties.
DomHelper: Highly optimized DOM creation and in-browser templates utility.
EventManager: Takes YAHOO.util.Event one step further and provides normalized browser event objects.
UpdateManager: Ajax helper to manage DOM element updates.

Q：Grid组件已经吸引了很多人的注意力。这个组件统计过有下载多少次吗？到目前为止，YUIE-EXT被下载过多少？
遗憾的是，我是最近两个礼拜才统计的，超过5000次下载了。


Q:文档和Grid、其它扩展的支持，准备得怎么样？
正如YUI小组的观点一样，我认为文档是非常重要的一环。所有组件都已经归档和附有若干的范例，而且对于每个组件，我博客至少有一篇贴子是用浅显的英文来说明每个组件是如何使用。


Q:上个礼拜，你发布了DOM Helper,一个可以让开发者注入DOM的工具，比起其它库的工具性能要高。未来新版的主要功能是什么？

DomHelper和模版类提供了提取DOM元素的跨浏览器方案。有别于其它传统API只是提供简洁、友好的方式，DomHelper类还提供了如HTML片断和模版的高效插入方法。与Scriptaculous Builder 、Mochikit之间的实时测试，这里可以找到http://www.ajaxjs.com/article/2007110518063601.asp（已译）。
。

Q:你Wordpress评论系统可以允许读者在不同的段落上发表评论，这一点，网友们很感兴趣，想知道你什么时候公开这个插件。
真正做这个评论系统的原因是能够让人们在教程中，或者是范例中，针对性地根据某一段代码、或者是话题，提出他们的问题或POST他们的想法。我不确定这能否做成WordPress的插件，因为我手工地修改过WordPress的核心程序。

Q:你下一个开发RoadMap是？
下一个版本是"Resizable组件"可以用户使某个元素可缩可放；还有一个Forms Library，弄成一个带有实时数据验证、数据绑定、普通桌面式的用户体验，还有一些idea如任务栏（像windows explorer）。Grid也会改进columns和渲染的问题。


Q:你期待中YUI是怎么样子的？
当然是。。。不要Grid组件了：-）。而我最想要的是History Utility。对比过那么多Ajax的项目，YUI是有它不错的地方，而且也会越来越好的。

Q:有其它开发者一起开发YUI.EXT吗？
现在已经有不少朋友在帮我忙，他们帮我解决了不少的问题（如Safari的）。
我很乐意收到用这个库朋友们的反馈和建议。目前是我一个人在做核心开发，当然我会接纳一些帮助。

Q:开发者如何参与项目的实践？
最好是来论坛多讨论 http://www.jackslocum.com/forum/，你也可以直接发邮件到JACK的邮箱。

**从http://www.ajaxjs.com/article/2007110521092306.asp接收

作为完整的归档，也顺道转帖一篇info对Jack的访谈。

《临发布2.0前对ExtJS作者Jack Slocum的访谈》
http://www.infoq.com/cn/news/2007/10/extjs20

作者 Scott Delap译者 Frank Cheung 发布于 2007年10月11日 上午8时9分
社区 Java 主题 Web框架

在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的代码库已经被不少开发者实践使用过，所以我们相信这是一个不错的开始。