ExtJS 开发总结
不知不觉2008已经走到了尽头,在这近一年中,一直不断的尝试用ExtJS做项目,从1.1到现在的2.2,吃了不少苦头,也有不少收获,总结一下,一起分享!
1. ExtJS的定位是RIA,和Prototype、jQuery等类库的定位不同。使用ExtJS做开发,就是意味着以客户端开发为主,不然就不叫RIA框架了,而Prototype、jQuery等只是辅助性的客户端框架,和ExtJS不在同一条起跑先上。如果一定要和其它的框架做比较的话,应该和Isomorphic SmartClient、Backbase Enterprise Ajax之类的框架做比较,当然,和他们相比,ExtJS还是有很大的优势的。
2. 使用ExtJS时需要解决如何服务端通信的问题。由于ExtJS只是一个客户端的框架,和服务端技术没有关系,也就没有相应的服务端的适配层,因此客户端如果要用ExtJS,则必须提供它需要的数据结构。ExtJS主要通过这几种方式和服务端进行通信:
- Ext.Ajax.request 做普通的异步请求,服务端可以根据实际情况返回JSON形式数据或者HTML片段;
- Ext.tree.TreeLoader 加载树形结构,服务端必须返回JSON形式数据,而且要符合Ext.tree.TreeNode的配置要求,否则自己做转换;
- Ext.data.Store及其派生类 加载表格形式的数据,服务端可以根据实际情况返回JSON形式数据或者XML形式数据,如果没有特殊要求,推荐返回JSON格式的数据;
- Ext.Element.update 局部更新,这个方法最总还是要调用Ext.Ajax.request方法,之所以把它单独列出来,是因为这种方式比较容易被忽视,但是在某些情况下还是挺 有用的,比如调用Ext.Panel.body.update()对某个Ext.Panel的内容进行局部更新,如果使用这种方式,那么服务端只能相应的 返回HTML片段了;
3. 使用ExtJS时的注意事项。ExtJS和其它的辅助性类库(Prototype、jQuery等)相比显得非常庞大,让很多很多初学者望而却步。经过近一年的学和用,对于ExtJS的使用,我总结了一下几个注意事项:
- 尽量使用ExtJS的方言。 ExtJS提供了很多有用的方法,解决客户端JavaScript常见的开发任务,常见的有查询HTMLDom,创建HTML元素,为HTML元素注册事件响应函数等,这些大可以全部使用ExtJS提供的方法,使自己代码构建与ExtJS之上,举几个例子:
- 查询ID为container的DIV下所有的checkbox,可以使用:Ext.fly(‘container’).select(‘input[type=checkbox]’);
- 在ID为container的DIV内创建一个按钮,可以使用:Ext.fly(‘container’).createChild({ tag: ‘input’, type: ‘button’});
- 为ID为container的DIV的click事件注册处理函数,使用:Ext.fly(‘container’).on(‘click’, handlerFn, scope);
- ExtJS的自定义事件很好用,可以实现一对多的通知,而且任何自定义事件都可以中途停止,只要有一个处理函数返回false。
- Store合并成一个文件 用ExtJS显示数据,自然就需要用到Ext.data.Store及其派生出来的类,可以考虑所有的Store合并到一个文件,这样对重用有很大的帮助。
- 脚本文件管理 尽可能的每个模块做成一个类,一个类一个文件,类似与Java或C# 的文件处理方法,每个文件注明其作用,依赖的文件等,如果太多的话可以考虑写一个配置文件,通过读配置文件来输出脚本到客户端。
- 调试和部署分别加载Debug和Release版本的脚本 ExtJS附带的例子中没有使用完整Debug版本的例子,所以很多人找不到完整的Debug版本的引用顺序,通过对Source文件夹下的ext.jsb文件进行分析,就可以得到正确的加载顺序,如下:
- Debug
- /ext-path/source/core/ext.js
- /ext-path/source/adapter/ext-base.js
- /ext-path/ext-all-debug.js
- Release
- /ext-path/adapter/ext/ext-base.js
- /ext-path/ext-all.js
- Debug
- 对Script进行压缩 对项目中有大量的JavaScript的话,对其进行压缩是很有必要的,这里我推荐的是ExtJS的论坛提供的JS Builder,可以通过配置文件来对Script和CSS进行压缩,据说ExtJS就是用这个工具进行压缩的,不过有一个缺点,就是不支持UTF-8编码。
4. ExtJS的优点和缺点总结。经过近一年的尝试,ExtJS的优缺点总结如下:
- 优点
- 一致的类库 这点在1.1版本时还不是很完善,但是到了2.0以后,ExtJS内部经过了翻天覆地的变化,特别是UI组件,有统一的基类,给人的感觉很像是一个运行在浏览器上的运行时框架,这一点只有在对ExtJS熟练了之后才能体会到。
- 托管页面呈现 ExtJS在发展到2.0之后,不仅UI类库一致了,而且渲染方式也是统一的,用官方的话说,是Managed Rendering,这一点使得UI的扩展也比较一致,有利于以后的维护与发展。
- 相对丰富的文档和示例 毫无疑问,刚刚接触到ExtJS的人多数都是被它附带的例子和开发文档吸引过去的,它的文档做的确实不错。
- 华丽而成熟的界面 ExtJS在2.0之后的界面真的是没得说,不仅华丽,而且相对很成熟。
- 缺点
- 没有合适的开发利器 毫无疑问,一个好的开发工具可以大大的提高编码的速度,但是对于ExtJS,始终没有一个完美的开发工具,可以推荐的有Aptana Studio, Spket IDE,和Spket 提供的提示文件,但是都是各有优缺点,都不完美,只能一边看SDK一边写代码。
- 没有界面设计工具 虽然有人提供了一个在线的界面设计工具,但是和Visual Studio提供的ASP.Net设计工具来说,真的可以说是天壤之别。因此,只能一边预览,一边写代码。
- 文档不全 虽然ExtJS提供的文档很丰富,但是还是跟不上源代码的更新速度,所以,经常要通过看源代码,调试才能真正解决问题。
- 不能编译 这一点可以说是JavaScript的缺点(如果能编译,就不叫JavaScript了),在实际的开发中,经常会敲错一些代码,比如大小写错误等,不能通过编译得到反馈,只能在运行时排错,导致开发的效率比较低下。
5. 使用ExtJS做应用的一些建议。多数人认为ExtJS的脚本体积很大,不适合放到互联网上,对于这一点,有如下建议:
- 部署到互联网上的Web应用一定要加载Release版本的ExtJS
- 可以考虑只加载必须的组件,build目录下脚本文件都是压缩过的,如果项目中用到的ExtJS的组件不是很多,可以只加载用到的
- 考虑使用IIS的文件压缩功能
- 使用Google的Gears,把所有的静态文件做客户端缓存
- 使用ADOBE的AIR,把脚本打包到客户端运行
总的来说,ExtJS是一个不错的框架,它陪伴我走过了精彩的2008,也许在未来的2009,我会转向其它的RIA技术,但是我至少会继续关注ExtJS,同时也希望这个框架能够顽强的生存下去。