关键词：ExtJs IMS RIA 作用域 id冲突 风格统一
1 引言
随着互联网技术的不断发展，网站的互动性越来越强，软件从C/S到B/S，又到了B/S结构的C/S界面体验，伴随着大量的富因特网框架的出现完成了一个螺旋式的轮回，目前在项目中使用的主要B端(浏览器端)框架中ExtJs、Flex、Jquery应该是使用频率最高的三个框架。
ExtJs是一种使用Javascript编写的与后台无关的Ajax框架。主要用于开发具有炫丽外观的RIA（富客户端）Web应用。它以其丰富的功能、华美的界面、良好的兼容性以及最重要的平台型等优势成功成为当今最主流的前端开发框架之一。
在投资管理信息化项目（简称IMS）中，项目的前端就采用了ExtJS框架。在实际开发中，ExtJs丰富的组件，极强的代码可重用性以及绚丽的效果都给我们的开发带来了很多方便和不错的体验。但是由于这是第一次使用ExtJs，大家都缺少经验，而且处于边学边开发的状态，所以遇到很多问题。现在IMS已经接近尾声，在此本人对使用ExtJs开发做了一点总结，希望能够为大家以后的开发提供一点帮助。
2. ExtJs开发要点
2.1整体规划
所谓整体规划，个人看来主要是界面、基本数据、公用功能的规划。
界面的规划主要是要对页面整体布局以及主要业务模块显示风格的提前确定。由于ExtJs应用系统的特殊性，它更偏向于RIA，几乎所有的页面以及操作都是在同一个浏览器选项卡中完成，很少牵涉到跳转页面的现象。因此如何紧凑、美观的对页面进行布局是前期需要规划好的。另外，提前确定重要页面的显示风格是十分必要和重要的。在IMS中，由于种种原因，前期我们没有花时间对业务页面显示风格进行讨论和确认，导致后期用户测试时提出页面风格不好的问题，以至于花费很大代价来修改页面显示问题。
基本数据以及公用功能的规划，主要是为了给开发带来便利。基本数据包括系统启动之后需要缓存的数据，全局变量等。公用功能的规划主要是将一些经常用到的功能以及函数等进行整合，然后提取出来，以便后面开发时能够方便的调用。
2.2 Id冲突
2.2.1问题来源
在IMS项目初期，由于缺乏经验的缘故，代码中遗留了很多隐患，在项目后期，这些隐患都暴露出来了。其中遇到最严重的就是组件ID冲突问题。
相信熟悉前台开发的程序员都知道，在HTML规范中，在同一个html文件中，任何元素的id值都应该是唯一的（虽然在重复的情况下，浏览器也能解释，但是当通过js调用getElementById()来获取元素时，页面会报错）。对于采用ExtJs开发的应用来说，基本上整个系统的前台页面都是由纯js编写的，这些js都由一个jsp（或者html、asp等）来承载（比如index.jsp），这就意味着这个页面中所有元素的id值都应该是唯一的。并且，对于ExtJs而言，在渲染页面的时候，它会通过定义的id值来获取元素做很多的操作，当出现id冲突时，页面就会出现很多意想不到的情况。
2.2.2产生冲突的情况
在ExtJs中，任何组件都有一个属性id，程序员可以自由定义这个id的值，如果不定义，那么ExtJs会自动为这些组件定义一个唯一的id值。由于Ext自动定义的id值是唯一的，因此不会出现任何问题。但是对于程序员定义的id值来说，这个值却不一定是唯一的。
一方面，一个项目中牵涉到很多的页面，这些页面是由多个程序员共同编写的，因此很可能在不同的页面中定义相同的id值，甚至是同一个程序员也有可能出现定义相同id值的情况。
另一方面，即使在编写的页面中没有出现相同的id值，在如下场景中，也会出现id冲突的问题。以IMS项目中的一个实际情况举例，我们有一个年度投资计划列表（如图所示），当点击查看按钮时，新建一个选项卡，进入这一条记录的详细信息页面，在这个页面中，我们确保没有定义重复的id，这种情况下没有任何问题。但是当我们再查看一条记录时，新打开的页面中所有的id都与前一个页面中的id相冲突，导致两个页面都变为空白。
2.2.3解决办法
针对第一种情况，我们可以通过简单的约定来解决。比如在IMS系统中，我们约定，在不同的业务界面中，使用类名前缀来标识每个组件的id，比如年度投资计划（InvPlan）列表页面，我们约定其id为InvPlanView，同样，对其创建编辑页面，我们约定其id为InvPlanForm，这样，通过简单的约定，不仅增加了代码的可读性，也解决了id冲突的问题。
对于第二种情况，有两种解决方案。
方案一：使用窗口（window）组件。其实对于第二种情况，问题的症结主要在于同一个组件会出现多个不同的实例，针对这一点，我们可以控制一次只能new一个相同的组件，实现的方式就是使用window。window有modal属性，当将属性为true时，window会对其后面的一切内容进行遮罩。这样，其他页面将不能操作，防止了同时new两个相同组件的可能。效果如下：
缺点：系统中可能有些页面比较复杂，需要完成的功能很多，用户在操作此页面时，可能需要查看系统中的其他数据，这时使用window遮罩不能满足这种情况。
方案二：添加唯一性标识。对于方案一使用window不能满足的情况，我们提出添加唯一标识的解决方案。具体实现就是，当new一个组件时，我们传递一个唯一的标志（这里使用uniqID来表示），然后在所有自定义id值里加上这个uniqID。这样，所有的id值都是唯一的，成功避免了id冲突的问题。
接下来通过两个实际例子来阐述uniqID的选取问题。
例1：还是前面提到过的年度投资计划页面，当点击某一条记录的查看按钮时，我们为InvPlanForm里的所有自定义id加上uniqID，按照方案二，当查看其他记录时，不会出现id冲突的问题。但是当我们多次点击同一条记录时，如果传递的都是唯一的uniqID，这样就会出现同一条记录的多个查看页面，显然这样的结果不是我们想要的。我们期望中的结果应该是，当多次点击同一条记录时，都只有唯一的查看页面。这就要求同一条记录的uniqID必须相同，为了达到这个效果，使用这一条记录（也就是数据库中某一条数据）的id来作为uniqID是最合适的。
例2：待办任务页面，当点击进入某一条代办任务时，页面会动态加载此业务（例子中是年度投资计划）的数据表单，如图所示。在这个情况下，如果我们再回到年度投资计划的页面里面，去点击查看这一条数据，由于uniqID使用的是数据的id，在这种情况下，页面的id也冲突了（还有其他几种冲突的情况，在此不作详细说明）。所以在这种情况下uniqID不能选取数据的id，最好的方式是直接使用绝对唯一的时间戳。
缺点：通过以上两个例子可以看出，这种添加uniqID的方式需要考虑各种可能出现的情况，然后对不同的情况选取不同的uniqID，这对整个系统的掌握度要求较高......
作者：虹信公司----研发部 陈飞