论坛首页 Web前端技术论坛

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

浏览 1567 次
该帖已经被评为隐藏帖
作者 正文
   发表时间:2007-10-15  
在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的代码库已经被不少开发者实践使用过,所以我们相信这是一个不错的开始。
   发表时间:2007-10-15  
好啊,有速度啊,这么快都有了2.0了呢..希望!
0 请登录后投票
论坛首页 Web前端技术版

跳转论坛:
Global site tag (gtag.js) - Google Analytics