闲扯 前几天看了几篇文章，其中包括管理、
软件工程和政府应用，但是大家都不约而同的的出一个结论，就是要选择合适方法
技术去做要做的事情。在做技术方面，尤其是行业应用方面，技术超前能够带来风险，但不一定能够带来足够的好处。所以，我概括行业应用设计的三个特性：稳重、简约、保守。当然，这算是题外话，以后有机会再细说。还是回到正题，Ext的学习感受。
问题 首先，Ext提供的是基于浏览器的用户界面组件，同时提供了与服务器交互的组件以及足够丰富的辅助和扩展。从搭建界面到和后台交互都可以依托于其上。
我们做软件，由于深入行业多年，多数项目都带有研究性质，因此，客户的需求往往会变化，后台模型也没有一个确定的。时常实用的方法就是原型方法，确定核心目标之后，在做需求的时候往往就要和用户交流系统功能：通过一个简单但是完备的原型系统去启发用户的需求，然后再根据用户的反馈调整界面和后台的设计，几个往复之后，系统基本成型，然后再去分析需要的数据以及数据建模。这种方式用了很久，虽然也有一些问题（如用户要求系统有若干线路状态的分析结果，可是却不能提供任何线路检测的原始数据，只有被提炼之后的线路状态报告，简单的说就是没有数据却要分析结果），但多数情况下能够适应这种类型的项目，因此一直沿用。
这种方式最大的问题是软件界面，以前做的时候一直都是用普通的静态页面来做，一则美工不在身边，做程序的人是不愿意修饰页面的，干巴巴的控件标签摆在页面上，虽然内容不缺，但看上去不美观；另外，每个人使用的字体大小、页面布局也是各有差异，集中到一起，看起来就好像收破烂收上来的似的。虽然后来让一个师弟做了统一的CSS，以及页面模板，效果也不尽如人意，毕竟需求期间，业务内容还是核心；最大的浪费是这些写出的页面到最后可能要被重写两到三次才可能纳入系统，也就是在需求分析期间做的这些工作除了明确需求之外没有什么作用，我有时候在想，与其做页面还不如用ppt模拟页面效果，或者干脆就是在纸上画。然而，没有系统的原型摆在那里，我们的用户是很难在脑袋里自己模拟出页面点击刷新的样子，必须有东西给他们看，所以，静态页面的原型就成为了不得不做的半无用功了。
后来看到了Ext，发现这个东西提供了非常丰富的界面，能够几乎一次成型，我有点兴奋，于是花了些时间在上面，同时这个项目来了，我也就建议团队采用Ext做界面了。
Ext是一个比较复杂的代码库，虽然文档齐全封装的也很好，但上手仍然很困难。好在我提前看了一段时间，能够在团队做一个简短的培训，让几个人迅速入门，然后，我负责解决日常遇到的各种编写上的问题，并构建各种例子代码，页面布局框架，让他们不用很理解就可以上手。因为前期只做界面，所以，框架之上，构建界面不过是复制控件，修改名称的工作。形成初步的页面布局方案供用户选择，同时进行部分报表的模拟。这期间因为不熟悉绕了不少弯路。比如，在布局的时候，经常多重Panel嵌套使用，导致滚动条不受控制。比如因为大批量粘贴代码导致错误后页面无法显示，然后只能一句一句调试等等。正所谓万事开头难，但是这种付出是有代价的。随着使用的日渐熟练，界面的构建速度也由两天一个的平均速度提高到一天数个（主要界面框架完成后，后面的基本大同小异了，速度提高也有此原因）。于是有人开始不满足仅仅搭建界面，写一些静态的数值装饰空洞的表格，开始将一些演示数据从网页中分离出来。
起先，演示数据是写入这些网页的固定地方的，定义简单的数组数据存储（SimpleDataStore）。这种工作虽然看上去简单，然而页面中有数据，有界面，非常混乱，而且一个页面为了演示动态效果，必须定义若干组数据，而这些数据的命名管理往往非常随意。前期的页面因为也是边学边写，结构乱，测试代码、被注释掉的代码以及各种任意命名的组件过多，连编写人员自己也记不得了。于是，我们约定了Ext变量的命名方式，规定在页面内的同一含义的内容采用同样的名字，这样，模板就可以派上大用场。所有的数据装载方式都采用XmlReader，模拟数据用不同的XML文件编写存储。这样，数据和界面就基本分离了。我当时在想，如果这样的效果完成需求分析工作，那回家的事情就只是将这些xml替换成写好Servlet或者Action返回给客户端就可以了。然而事情并没有我想象的那样简单。
第一个遇到的问题便是前期的代码太过混乱。虽然统一的变量命名已经规定下去了，但是并没有说什么时候需要将对象赋值给变量，什么时候可以直接写入框架，结果造成各种各样的代码，有的人长长的处理函数写在了界面中，对象的正常缩进被插入的函数搞得一塌糊涂，而有人则是对象就定义变量，一堆变量然后插的到处都是。
第二个问题是AJAX的实现方式。Ext提供了很多的实现方式实现对服务器端的请求，有的封装在对象中，如Store.load有的则需要自己使用Ext.Ajax对象的方法请求。为了精简代码，充分利用封装好的库，应该尽可能的使用已经封装的方法，可是偏偏有人无论何时都调用Ext.Ajax，代码冗余很多；有人load数据之后又重绘一次表格，进行了很多不必要的操作。
第三个问题调试上的困难。这个问题很让人头疼，JavaScript的调试非常困难，好的IDE也不是没有，只是为了写页面，装上巨大的盗版VS2005或者在Win上跑得慢如牛的Aptana和Eclipse都是我不想要的，结果还是回归了文本编辑器。
我要求只要是能够独立显示的组件就独立调试，将其视为一个模块，这个模块可能只是页面上的一个信息显示部分或者是几个form输入框。对于不熟悉Ext的人，先将这几个要显示的组件放到单独的网页里面调试，显示正常后加入他们操作完成后的需要调用
其他部分的方法，也就是他们对其他部分影响，然后是其他部分的操作可能对它们的影响。实际上就是一个出口也一个入口，对于简单的组件也就是两个函数。写完后要对这两个函数进行测试并测试内部的各种事件响应操作。完成之后将他们从单独的网页中提出来按照组件，入接口出接口的顺序放在一起加入框架页面，并标识长分隔线与其他代码分隔开，并进行注释。然后组合这些组件成为页面中的部分面板，再由这些面板插入到正题框架的各个部分中去。这样，第三个问题就被化整为零的解决掉了（如果三两行代码还调试不通，那我也只好发飙了），同时也对第一个代码混乱的问题提供了解决方法，只不过，由于每个人的水平和学习领悟能力有限，每个人能够承受的最小组件的代码量是不一样的，所以这个我暂时也没有要求（等以后有了经验，而且都熟练了，这个也要根据项目的实际情况确定下来，不然，代码乱得要死）。对于第二个问题，没有太好的解决办法，只能一个组件一个组件的去讲解他们的数据请求方式并写好示例代码供大家参考。
需求完成，规范代码，接下来就是服务器端的接口程序了。这次用的是WebLogic，实际上，我觉得如果按照原先这种纯粹的无连接请求数据的话，后台用什么是无所谓的。当然后来发现WebLogic除了狂吃内存这一点太BT之外，其他还是蛮不错的。因为页面采用Ajax发送请求，自然WebLogic的页面流转是没有太大的用武之地，只是需要针对每一个请求写一个或者几个Action就可以了。而且，各个子系统之间的数据访问也是通过这种接口，大大减少了子系统之间数据共享的复杂程度，对整个系统的后续扩展和
开发也打下了很好的基础。
现阶段，这个项目的开发就到这种程度，后面针对接口的设计还有很多问题我没有来得及总结，大概只能等过段时间闲下来的时候再说了。
流程 整个一个流程就是
1、先根据需求设计用户界面
2、为界面编写测试数据，并通过DataStore动态装载到界面中
3、将测试用的静态数据改为动态数据
前两步要反复迭代，和用户讨论沟通，确定清楚，用户一般也比较乐于见到提出的意见很快变成可见的东西，也可以启发他下一步的需求和想法。第三步当然比较复杂，包括
数据库的设计，业务模型的设计等等，但至少我们可以着重关注后台的事情而不再需要为前台操心了。
附件 附件中是一个我写的Ext页面代码模板，里面用注释将代码的基本结构分开，这样编写的代码会稍微好看一点。
点击下载http://www.3snews.net/batch.download.php?aid=4206
