开发EXTJS一年半了，一边做Java一边做Extjs。我也在EXTJS官方的国际化资源文件中提过一个修正版的中文资源包，现在在最新的3.1.0版本中的国际化资源文件就是我去年提的那一版修正版。
我在项目中积累了不少失败的经验和心得，我们单位在国内应该是第一批使用Extjs开发大项目的公司吧，大约两年前就开始准备了。
那么，我就我在开发Extjs中遇到的一些困难、问题以及前后台搭配的一些冲突上做一个简短的介绍吧。
1.前期不够投入
这个怎么说呢？在前期调研的时候没有引起足够的重视，总以为Extjs嘛，无非就那么点控件，那么点东西。new一个window我能使就行了。需要一个grid 我就加一个gri d。结果导致代码运行效率的极度低下，变量名没有好的管理。采用过程式的编程，而不是OO思想。这个是最大的败笔，此问题至今没有被解决（我进去上班的时候他们已经编写了N行代码了，重构是不现实的了。）。目前还有很多公司依然偏执的认为，EXTJS就是JavaScript 嘛，在牛也是JS。最后，出现问题之后，就开始说：“Extjs效率太慢，无法容忍。根本不适合开发大型项目。”
2.对API的不了解，以及资料匮乏。
这个直接导致了N多无用的代码，说出来不怕大家笑，我曾见过ComboBox不使用displayField和hidden Field 来获取value和rawValue，反而是自己在哪里写了N多行代码来获取这两个值。（不过大家也要认识到，当时做EXTJS的国内很少很少，能写出来，也算不错了。）那么，这种偏执，导致了自己的代码经常性的报错，不可预料的一些错误。焦头烂额之中忽然看到百度或者Google 上有这方面的资料。恍然大悟。后来网上资料慢慢多了，又出现新问题了，那就是下面要说到的问题。
3.不相信自己的能力，过度依赖百度和Google
我刚进单位的时候，我写一个继承（ext end）。都要问：“这是什么写法？我没见过呀。百度Google上没见过呀，这样写能行吗？”。这个思想的产生，不是因为别的，而是因为在开发初期不重视 EXTJS，偏执的埋头写自己的代码造成了很多损失之后，开始产生了不自信。从而当出现问题之后，没有自己去反思为什么会出现问题，焦头烂额之后就直接去开帖子问别人，百度一下，Google一下。不优先考虑API和它的源码。这导致自己的不自信。认为，如果从百度上抄来的代码不能运行，那是别人的错而不是自己的错。别人写的代码自己在百度或者Google上没见过，就认为不行。三思而后行。
4.前台与后台的那些纠纷
大家知道，Extjs中很多数据要显示出来，必须要有一个字段对应后台的数据，例如grid中的columnmodel，我前台有id，后台也要传送一个 id字段我才能显示数据。但是在实际开发中，出现问题了。后台建库建表的时候，从未征求过表示层的意见，也是近似偏执的认为，建库建表与表示层没关系，到时候处理一下塞到前台让他们显示就得了。这下苦了表示层了，一条数据上来，字段与前台不对应，怎么办？比如，前台一个grid中的字段显示的是年月日，而在数据库 中年月日是三个字段（只是打个比方），那么我就要在Action做字段拼接，而这个步骤，应该是在数据查询上来的时候就拼接好的（实际应该在业务逻辑层做这个事情）。结果导致了什么？Action当中充斥了大量的StringBuilder和循环，搞得Action中杂乱无章。好不容易发现来了一条比较顺手的数据，只要JSON-lib转换一下就搞定，可惜，里面居然有length之类的敏感字段。苦闷。为了多个表的数据兼容（例如A表和B表要同时显示在一个Grid里面，A表B表字段不一致），更是写了无数的逻辑处理。当然，我这里描述的可能有点问题，实际开发中的困难真的是只可意会不可言传……
5.页面逻辑与后台逻辑分不清
打个最简单的比方，我需要截取时间，来将某个视频截取出一段用于播放，这个逻辑应该在什么地方做？页面吗？我想不应该吧，JavaScript可以做时间运算，但是这个运算最终要把运算结果传递到后台，再由后台将切割好的视频流发送到前台，为何我们不能在后台完成这个逻辑？JavaScript毕竟不擅长来处理逻辑。一旦遇到异常，JS总是要花跟多的时间去处理这个异常，相反，Java是很擅长做这件事情的。
6.JS的调试
还是那句话，由于前期（在我进入公司之前）不重视表示层，并且由于各种原因。有些东西不能在火狐上跑，就抛弃了火狐，认为我们的东西只要运行在IE上就行了，写了一堆不兼容火狐的代码。这下惨了，亲爱的火狐以及Firebug离我而去，调试成了我们每天茶余饭后必谈的话题。最后我找了个折中的方法，CommonJS插件来调试，可是由于种种原因，在IE6上运行的效果不理想。于是我不得不使用log4JavaScript在哪里死磕。浪费了时间。浪费了精力。
下面，我就我所遇到的一些问题提出一点开发上的建议
1.保证自己代码的命名规范，JS中的注释一个都不能少，Java通过Eclipse能定位到变量所在的文件，JS你Control健按死了也定位不过去（Spket 只能定位到声明，不能定位到文件）
2.保证自己所写的模块能个单独运行、测试。模块与模块直接不应当耦合过于紧密。过度的耦合你会发现，当我要替换某个模块的时候显得相当的困难。
3.在讨论数据库、后台、整体流程的时候，表示层一定要竖起耳朵来听，不要到时候因为数据库少了一个字段来在Action做表连接查询。
4.要让别人知道，JS其实不像他们想象的那么简单。
5.多看API，多看源码，少上Google和百度。坚决不拷贝网上现有的例子作为己用。
6.出了问题先查原因，多写笔记。错误肯定不会只出现一次。
7.打理好自己的JS文件，动一个西一个，名字词不达意你会痛苦的。
8.你不是一个人在战斗，你不是在以学习的心态来写EXTJS，你现在是在用它来创造价值。一个人的力量是薄弱的。
我个人感觉Struts1与Extjs配合的其实不是很尽如人意的。相比较来说，Struts2要好一些（实际上Struts已经没有存在的必要了，Servlet或者SpringMVC也能很好的解决需求。）。JSON-Lib的版本，我觉得Struts2目前自带的版本过低，有机会最好替换成最新版的JsonLib。还有就是，前台如果没有特殊的需求，就用HTML页面吧，JSP也是要编译的，首次运行比较慢，而我们做开发，几乎都是首次运行。这样能减少不少时间。
能省掉的代码尽量省掉，过多的代码只会造成你的bug增加，没有任何好处。
敢于怀疑，很多时候（特别2.0）。有些BUG是由于EXTJS自身带来的，而不是因为你代码写的有问题，所以，看清楚究竟是哪里出了问题，对你来说能把握住问题的关键。
Extjs是基于JavaScript的，也许你觉得你根本不会JS也能写出一个window，觉得这样就可以了。但是你错了，如果对AJAX没有一个深入的了解，你永远都只停留在会写，而不会上升到怎么去写的更好这个层次上来。如果你仅仅是为了逃避繁琐的CSS、DOM和JavaScript而使用 EXTJS，我劝你最好还是花时间去了解一下。我不会害你的，放心。
不要偏执，如果看这篇文章的过客是一个准备用EXTJS来开发的调研者（经理大人或者主管大人），希望您能有足够的重视，EXTJS写的不好，会让您大失所望。必要的精力和资金投入，是必须的。并且请在开发周期上稍微长一点。
Extjs就像EJB，未来的路怎么样，自己琢磨。存在即是理由，说EJB烂的，EJB依然在很多地方被应用。说EXTJS不适合大型项目的，试了才有发言权。轻量级与重量级的孰优孰劣，自己考虑吧。
也希望高手达人能分享自己的心得与经验，让我从中受益。不过本帖不欢迎擡杠的人跟帖，讨论问题而已，好自为之。客观评价。
谢谢。
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/zhangxin09/archive/2010/06/28/5700502.aspx
