问题一：要不要采用javascript框架？

我刚到公司的时候，我们的技术架构师是不同意使用javascript 框架。理由很多，javascript 没有得到应有的重视是主要的原因，他一直强调我们做的是应用系统。所以他只在网上找到几个js放在项目下面，然后页面上很乱，要写一颗树展现真是麻烦又麻烦。而且大家的javascript水平都很一般，基本只是稍微了解一点。用的最多的还是数据校验，写的方法还是document.form1.formname,document.add['id']之类的写法。这让我这个天天关注界面的技术人员(冒昧自称技术人员，其实只是在界面层上有点研究而已)真是抓狂。很讽刺的是，为了使用一个小窗口弹出错误信息，把jqeury+ui搬出来。整个项目也只有这么一个地方用到jquery,去年的时候jquery的人气正在攀升。我来了之后，由于自己辈分小，在技术上说不上话，后来大家界面上开发的时候遇到这个那个问题解决不了的时候，大家慢慢的认识到了我的价值。新的项目领导让我负责界面规范这块，公司也想把这个项目做成一个产品。经过很多次“力荐”，我终于说服了大家，我们不能再"IE only" 了。

我认为使用的理由： 一，我们要有兼容各种浏览器的能力，现在新的浏览器大战正在打响，将来的浏览器市场还很难说。在css这方面 我借鉴了ext 的兼容思想，在body标签上加上class "IE IE6",这样我们不要使用hack 去兼容浏览器了。对于javascript上，基本上只有IE和非IE的差别了。主流的javascript框架都提供了很好的浏览器支持。二，用javascript框架的目的是提高开发效率。这与主流的javascript不谋而合。三，web应用正在飞速发展，界面层应用越来越复杂，javascript不在一个校验数据的脚本了，ajax的应用能很好的提升用户体验，有些场合使用ajax，用户操作更加方便。举个很简单的例子，很多的记录需要排序，虽然在数据上来看，只要改变排序值能解决问题，但在界面上，难道要用户去填写排序值，这样用户会觉得很难操作，而用上sortable，这个问题不仅简单，而且操作起来不知道清晰多少。我们从传统的c/s走到b/s不仅是因为b/s 不需要安装，升级容易。还是因为b/s具有更前的表现力。

当然，反对使用javascript框架的理由也很尖锐。一，开发人员的水平很难以掌握现有的javascript框架。二，大家坚持认为，其实现在用的javascript的地方还不是很多。从需求上将屈指可数，tree,borderlayout,grid,calendar。

对此，我提出的想法就是，大家如果觉得难以使用的话，我在javascript框架上做一次封装，降低使用难度。第二个理由更好说，虽然现在使用的地方就那么几个，那好，你能拿出更好的方案么。曾经架构师说，我们希望每一个界面控件都是单独的，能单独使用。当然现在的主流javascript 都是这样的。这样，我就在大家仍用怀疑的眼光注视我的时候开始了javascript框架之旅。

问题二：用哪个javascript框架？

这个问题不是在讨论或者争执哪个好哪个不好，未免大家再又争执，我让他们自己找javascript框架，甚至可以把他们最熟悉的拿出来使用。大伙都说没有时间，这样我也不担心有人说后话了。

我把目前主流的javascript分为三类。

诸如：prototype/jquery/mootools这样的javascript框架，只能是javascript工具。他的优势就是扩展性强，社区支持很好，尤其是jquery

第二类就是：yui/ext/dojo/qooxdoo这样的框架。他们是一套全系列的纯客户端的ui解决方案，使用方便，能满足我们的需要。缺点是入口很高，适用于做富客户端。虽然我们现在的应用还是很多，但是还没有到那个地步。

还有一类就是与服务器端技术结合的ajax框架，他只能叫ajax框架,他基本只做数据交换。事实上只要做一个简单的servlet(j2ee)或者HttpHanlder(.Net)再在客户端加以封装，使用起来也是很方便的。所以这类ajax框架我认为不需要考虑。

在我看来，并不是那个框架绝对的好坏，而是什么样的框架能最好的满足你的需求。

论个人阅历上来讲，三类的多个框架我都知道一二。但是我最喜欢jquery,所以使用了jquery了，他的好处就是轻量级，扩展性强，现有的插件足以满足需要。代码非常简介而且执行效率高。于是我找了一大堆jquery插件。再自己封装城稍微简单的方法。本着不重复发明轮子的原则。很多的界面问题都能解决了。

问题三：真的是那样么？

时至2009,项目完了，到了需要再次封装城产品的时候，麻烦也就来了。我发现虽然jquery插件很多，很全，但是由于是百花齐放，我就不想修改里面的代码。慢慢的使用发现很多插件不是很稳定，像jstree,jquery ui 由于先前用的版本比较低，导致很有的bug自己写一些修正。现在回过头来看那时候做的东西，发现新的版本已经修复了这些功能。而换上新版本的jquery，变化还是蛮多，比如jquery.browser就不推荐使用了，怎么办。

将来。

本文就是在使用jquery之后，发现维护工作量也不小的背景下写下来的。我不知道是不是我当初选择jquery是错误的。是不是应该选择ext 之类的有着更强表现能力，更稳定的框架么？现在的代码还是不是那么理想。由于很多的历史原因，大家还在用ecside ，jscalendar。使用ecside是因为历史原因。使用jscalendar是因为jquery还没有一个日历控件能支持时间的。我一个人的精力有限，而且我很多的时间都在写项目代码(说到底还是领导不重视)。我担心我当时做的决定会对将来造成负面影响。

冒昧发在首页上，真诚的希望大家提出自己的看法，在企业级应用系统上界面层应该怎样做，文中的有些观点如有不对的地方还请大家指教

之所以要把sql server 2000 jdbc 分页单独来说说，又两个地方还是值得一提，一者是sql server 2000要实现数据库分页是比较麻烦的事情。二者是jdbc查询出多个ResultSet 的取法。

先在项目的classpath中添加msbase.jar,mssqlserver.jar,msutil.jar 怎么来的就不多废话了。需要说的是我最先用的sql server 2005 jdbc驱动sqljdbc.jar放到项目中，后来的程序是报错的。回头想想，报错有理，sql server 2005 已经支持rownum 分页了。

先说说sql server 2000的分页的实现，目前实现方法大概是那三种。我个人还是喜欢使用存储过程,原因是使用非常方便，至于使用的存储过程，这里还是放出来看看，估计大家用的都大同小异。

IF NOT EXISTS (SELECT * FROM dbo.sysobjects WHERE id = OBJECT_ID(N'[dbo].[Pr_QueryByPage]') AND OBJECTPROPERTY(id,N'IsProcedure') = 1)
BEGIN
EXEC dbo.sp_executesql @statement = N'create     procedure   [dbo].[Pr_QueryByPage]   
@sqlstr   nvarchar(4000),   --查询sql  
@currentpage   int, --第页记录条数  
@pagesize   int --每页显示记录 
as   
set   nocount   on   
declare   @P1   int, --P1是游标的ID  
@rowcount   int   
exec   sp_cursoropen   @P1   output,@sqlstr,@scrollopt=1,@ccopt=1,@rowcount=@rowcount   output   
select   ceiling(1.0*@rowcount/@pagesize)   as TotalPage,@rowcount as [RowCount] 
set   @currentpage=(@currentpage-1)*@pagesize+1   
exec   sp_cursorfetch   @P1,16,@currentpage,@pagesize     
exec   sp_cursorclose   @P1   
set   nocount   off  ' 
END
GO

这个存储过程的实现，使用了三个系统存储过程sp_cursoropen ,sp_cursorfetch ,sp_cursorclose 从字面上的意思大概是他叫结果集使用游标打开，然后读取其中的@pageSize条记录，所以单从查询上来讲，性能是不及使用select top 之类的实现。

使用起来非常容易，exec Pr_QueryByPage 'select * from yourtable',1,10  就可以了麻烦的是他返回的是三张表。第一张表是查询的表，但是没有记录。第二个表一行两列，第一个列是总页数，第二个列是总记录条数。第三张表才是需要的数据。这就造成了取的时候有点小麻烦，因为之前只知道，在.net中可以直接fill(DataSet)，然后DataSet里面可取DataTable。但是在jdbc里面我映像中ResultSet 只能容一张表。后来找了一些资料，原来PreparedStatement,CallableStatement,Statement都支持查询返回多个ResultSet ，好了，非常好。 下面是我使用CallableStatemnt取到的结果集。

CallableStatement cs = conn.prepareCall("exec Pr_QueryByPage 'select * from ckdmzd',1,10");
            ResultSet rs = null;
            /**
             * execute returns :
             *     true : returns ResultSet(s)
             *  false: returns rows affected
             */
            boolean hasResultSet = cs.execute();
            if(hasResultSet){
                /**
                 * skip the first ResultSet
                 */
                rs=cs.getResultSet();
                /**
                 * second ResultSet : pageCount & recordCount
                 */
                if(cs.getMoreResults()){
                    rs=cs.getResultSet();
                    while(rs.next()){
                        String pageCount=rs.getString(1);
                        String recordCount=rs.getString(2);
                    }
                }
                /**
                 * the thrid one is the paged result
                 */
                if(cs.getMoreResults()){
                    rs=cs.getResultSet();
                    while(rs.next()){
                        // do somthing with ResultSet
                    }
                }
            }

这样就实现了分页，网上很多人测试了，这个方法的性能不及别的方法，这里我要指出的是，别的方法是不能返回总的记录条数的。而要知道总的记录条数，通常需要select count(*) from ( your sql) 这两次查询叫起来的时间未必会少。

总结

使用上述方法实现sql server 2000 jdbc 分页，使用方便，性能还说的过去。我不知道sql server 2005 的查询性能是否又提升。