排版格式化:
http://blog.csdn.net/liu251/archive/2010/10/27/5968510.aspx
我以前主要是做在线支付相关业务的,公司接到一个银行令牌的业务,我们开发组就转战于管理系统的开发,开始做令牌及相应的机构和人员管理。之前,我们开发组一般做关于页面的开发主要是jQuery来操作HTML DOM,这次为了做WEB版的管理平台,我做了很多调研,最终基于版权、网络上的可用资料、完善程度、系统的使用环境(内网)四者的综合考虑,选取了ExtJS 2.0.2作为页面的开发框架-ExtJS相对于Dojo确实更适合与做前端的开发框架。下面是我们小组在开发ExtJS项目中遇到的一些困难、问题及解决方案做一个扼要的介绍吧。
1.技术积累不足如上所说,开发团队中总共有4个人,其中只有2个人(我是其中一个)做过比较复杂的js页面开发。我在前期调研的时候只是写了一个通讯录管理的demo,然后在搭建的平台框架上开始实现一个功能(表格查询),同时开发小组根据demo来学习extjs。在完成这个功能之后,我们开发小组开始根据根据这个功能页面来编写其他的查询功能页面,我则一边开发新的功能示例,一边测试项目需要的ExtJS技术(动态菜单、ExtJS常见的优化技术)。在每个人完成功能模块后,进行页面代码review的时候,发现很多变量没有使用命名空间,导致大量的全局变量不易管理。有些控件的重用率很差,有时同一个窗口代码在不同页面上被多次Ctrl+C/Ctrl+V;每次的按钮事件都创建一个新的控件,例如右键菜单。还好是在初期发现这种问题的,重构优化、抽取共用代码。
做ExtJS的管理界面,项目开始的时候就必须做好详细设计,变量名规则、公共代码(这是个费精力的事,除非能够确认,否则开始编码的时候分开来写,然后在不停的重构来抽取)、前后台交互时的参数名、代码注释等,这些都是要考虑的。
我发现做ExtJS就和编写Java代码一样,在空闲的时候多看看常用控件的API接口,如果有精力的话读实现的源码更好,毕竟在编程过程中肯定要做一些特定风格的控件,如果了解相关控件的源码,那么山寨创新也比较方便了。而且也可以防止编码过程中因为对API的不了解,自己重复造轮子的现象出现。
2.前台与后台角色的规划
因为开发小组的ExtJS技术薄弱。在开发过程中遵循一个约定:规定好前后台交互的参数名后,页面只是负责渲染显示数据,后台的负责数据的逻辑处理和组装数据。每次的http请求都是由后台将格式化的数据传到前台显示,这样做能够避免页面大量字符串组装、类型转换的操作、JS代码在浏览器中的兼容问题。
3.ExtJS的调试这个管理平台有个功能需要访问用户电脑的USB接口,而且用户的电脑浏览器多为IE6。我们开发的时候因为大多数的JS是基于ExtJS的,除了ActiveX插件,少有浏览器兼容性的问题。所以我使用可爱的火狐及Firebug和HttpFox作为开发和调试的工具,使用IE6/8的运行效果的验证环境。有些同事不喜欢使用这些调试工具,直接用IE下的alert来和bug死磕,后来在劝说下改用Ext.log()来输出log信息,但是在提交代码时,未将这些alert/Ext.log()完全删除,最后集成测试的时候还要走查一遍代码……。
总之,做js开发,Firefox+Firebug是必须的,实在不愿意用也可以用Ext.log、BlackBird(http://blog.csdn.net/liu251/archive/2010/02/04/5287185.aspx)来输出log信息,别用alert折腾自己了。有技术储备的话最好使用js单元测试来简化日后代码维护的代价。
总之:
l JS代码要有规范的命名和命名空间,方便代码中查找、定位和管理,JS中的注释应该尽量详细,这关系到以后的维护。
l 有空多看API、使用手册和源码。
l 需要某些特殊的控件,先Google下,看看能不能找到类似的扩展,再在上面做二次开发。
希望我完成的第一个ExtJS项目的心得与经验能够对大家有些帮助。