XMLHTTP和浏览器端表现技术的讨论

我也对robbin没有用过就臧否xmlhttp。我门公司运用这套机制，已经做了两个上千万的大项目（国税和电信BOSS），DLEE说的确实是经验之谈。但是在处理大数据量时，我们还是遇到了点麻烦。移动运行商一般有银行托收，在处理托收文件时，每次可能要在前台用JS读取，分析一个很大的托收信息文件，导致页面白茫茫的一片，客户端的CPU一直占用，不知道DLEE碰到过这种场景没有，有什么解决方法

就拿你这个例子来分析一把：

Client(Javascript  parse XML)
Server(Servlet parse XML)
页面动作由Javascript响应，处理，封装数据为XML，调用XMLHTTP控件，通过HTTP协议和Servlet通讯，与常规HTTP相比，无非就是数据封装为XML格式而已。传统数据提交通过Form，有一个页面提交过程，而XMLHTTP省略该过程。

1、Client端要实现积累下来可重用的，比较成熟和完善的Javascript库，用来构造，解析XML(Javascript操作XML，大概是通过本地ActiveX调用MS XML，个人猜测，不对请指正)

2、Servlet端要写一个XML解析器，从XML中分离数据，最好的情况下就是能够积累一个比较成熟和完善的库，用来操作，解析各种情况下的XML，以及处理各种特殊的情况

3、由于交互过程通过Javascript来调用XMLHTTP来驱动，因此页面中的Javascript代码可以预见到有相当程度的增加

4、由于节省了和服务器交互过程，页面数量以及页面代码的中的状态控制将减少很多。

5、对于服务器端编程来说，传统的方式和XMLHTTP的方式没有本质区别，并且XMLHTTP方式下，还需要自己多一层XML解析的工作(如果条件2具备的话，就省下了)

因此通过上面我的分析(如果有错误，请指正)，我们来看服务器端，如果我给webwork/strtus加上一层XML解析封装机制(也许可以通过AOP方式加上)，那么我完全可以采用如下架构：
Javascript + XMLHTTP + Webwork

这说明XMLHTTP和Java Web框架是不冲突的，抛开XML的封装之外，两种方式在服务器端编程不会有什么不同。XMLHTTP简化的是客户端的Form，而不是服务器端，所以我对你说，用了XMLHTTP，就不必像Struts/Webwork那样写很多Action/XML表示不理解。也许你可以拿一个简单的例子出来，我们再分析分析。

我都说了半天了，希望你们拿出来一个例子，项目金额大不证明技术运用就是成功的，我还见过用EJB技术做的上亿的单子呢。就像上面帖子所说的，实现一个持久对象的CRUD操作，在一个页面上面实现条件查询，分页，增加，删除，修改。所有的前台页面代码，Javascript，后台Servlet代码，以及你的后台Servlet如何调用DAO层实现这一系列操作。然后我也写一个对应的例子，我们对比一下，不就都清楚了吗？总比现在这样总是强调我没有做过我没有经验，所以我就没有资格否定要好吧。不要光说不练嘛

请教谈不上，potian 太客气了。FireFox 和 Mozilla 一样是基于 Gecko 的引擎，Mozilla 支持 XMLHTTP，所以 FireFox 肯定也是支持的。Mozilla 与 IE 的 XMLHTTP 对象的接口是兼容的，唯一的差别是对象的创建方式不同。
WebFX 做了一些控件来封装 IE 和 Mozilla 的差异，除了事件机制没有封装以外（因为差异太大），其它的主要部分（包括 XML DOM、XMLHTTP，etc.）都封装好了。
http://webfx.eae.net/dhtml/xmlextras/xmlextras.html
Sarissa 这个开源项目的灵感就是来自于 WebFX 的这些控件，想要开发出一套不依赖于具体浏览器类型（IE、Mozilla、Opera）的 JS 控件库。
http://sarissa.sourceforge.net

晓钢以前和 Quake Wang 的讨论：
http://www.blogcn.com/User6/caoxg/blog/3170126.html

页面白茫茫一片我想可以这样处理，设置一个 IFrame，把一些操作放到 IFrame 中去执行。CPU 一直占用我没有想到很好的方法，我想 JS 确实不适合分析很大的文件。

我在 3 月份 JavaEye 的讲座中说道，我认为这种开发方式是一种更先进的开发方式，因为这种开发方式代表了 W3C 所希望的 Web 开发将来的发展方向。W3C 希望将来客户端和浏览器之间传递的都是 XML 格式的纯数据，具体如何显示由客户端的显示设备根据自己的能力结合客户端的脚本或者样式单（CSS、XSLT）来决定（表示层是显示设备的事情，不是服务器的事情，完全依靠服务器端的能力是无法真正做好的，而且做起来会很复杂）。采用这种方式将来的客户端即使不用浏览器，换成 Delphi 客户端、PDA 或者什么其它设备都是没有问题的。

别的方面我没有多少经验，不敢多说话，但是在 Web 层，我们大量采用 XMLHTTP 以后，发现做很多事情确实比以前简单多了，以前那种传统的基于 Form 的请求/响应模式做起来确实是很繁琐的。

关于xmlhttp，我从2002年开始使用，当时是我的经理开始带我用的（水平非常高）。他用xmlhttp写页面，可以做到类似C/S结构那种，编辑table，点中文本类型，就是一个inputbox，如果是选择的就是下拉框，当你点了其它地方后或者点击保存，数据就保存了，可以追加一行，删除一行。确实很牛，但是当时的问题在于写出需要大量的JS代码，并且不是一般的复杂，另外由于公司这方面不是很重视，所以没有进行封装成框架，所以这些东西就没有继续下去，只是偶尔还是用这种技术。后来我和经理都离开公司了。
    但是在我后来的经历中，也曾经使用过。发现的问题基本上和robbin所说一致。如果没有类似hibernate这样的框架，我是不会大量采用这种东西了。如果自己写的话，代码量非常大，非常复杂，并且js没有好的开发工具和调试工具，和服务器端相比，工作量至少要增加一倍（当然了，如果你们自己有框架就不一样了），此外，维护困难也是一个大问题，这对开发人员的js水平要求非常高。
     在公司后来的时候，我的经理去发展flash做客户端了，我没有参与这些东西，不过感觉他们还是比较满意的。

robbin，这些我们都有很好的 JS 控件库。至于你说的积累问题，我觉得在各个层次都存在，似乎不能作为抵制 XMLHTTP 和 JS 的理由。其实再好的 MVC 框架（例如 Webwork）最终仍然需要解决好提高页面的表现能力（Rich Client）的问题。这就需要在客户端开发方面以一种注重积累的方式做开发，形成一套顺手的控件库。这方面的工作我觉得不能寄希望于开源软件，其实开源的也有很多非常不成熟的东西。

这个问题在有比较强的 JS 开发人员的情况下根本就不是问题，谁说过页面上有了一些 JS 就是不好的？

至于 XMLHTTP 并不能减少 Struts 中 Action 的问题，其实可以说是 Struts 本身的设计问题。Struts 是一个完全基于服务器端的技术设计出来的框架，在主体设计成型之前从来就没有考虑过客户端的能力。Struts 结合 XMLHTTP 和 JS 其实不如晓钢和 Quake 所讨论的 XWork 结合 XMLHTTP 和 JS 更好。如果用 Flex，假如他们提供了非常强大的控件库的话我认为可能比用 JS 更好。JS 的优势在于就在手边上，不需要花钱即可以使用，而且会 JS 的人比会 Flex 的要多得多，培训成本也比较低。

dlee 
     因为你们公司已经有了比较成熟的框架，当然自己用是最好了。不过其他人如果要用的话，我觉得最好也去先写一套这样的框架，否则我觉得还不如现在传统的开发方式。

我什么时候说我“抵制“XMLHTTP啦？我只是说在没有一套成熟的完善的开源的XMLHTTP的客户端和服务器端框架之前，应用XMLHTTP的TCO比当前的服务器端解决方案要高出不少。



页面表现能力不是MVC框架的范畴，你觉得我上面说到用AOP的方式给Webwork增加一层解析，从而实现 Webwork + XMLHTTP的架构如何？这正说明了页面表现不是MVC要实现的事情。 换句话说，那我是不是可以说，再好的ORM，也要解决页面表现能力的问题呢？再好的开发工具，也要解决页面表现能力的问题呢？再好的编程技术，也要解决页面表现能力的问题呢？



做为一个具体的公司而言，选择XMLHTTP，并且围绕XMLHTTP积累一套控件库，这完全是可行的，并且上面已经有那么多人都站出来证明了这一点(虽然尚未有人给我展示一个小例子)。

而我的关注点则是围绕XMLHTTP的解决方案是否能够成为一种流行的、主流的技术方案。显然，在没有一套成熟的、完善的、开源的框架这前，他不能成为主流解决方案。这里我用了三个修饰词，“完善”，“成熟”，“开源”，这缺一不可的，到不是说我寄希望于开源，而是没有好的开源框架的话，你不可能指望每个人都去购买，因此也就不可能普及。



我说过有JS就不好了吗？既然你也承认这些问题的解决需要比较强的JS开发人员，这也证明了基于XMLHTTP的解决方案需要比较好的Javascript技术人员支持，那么这难道不是项目的成本吗？ 不是一种技术普及的一个门槛吗？

我是比较同意robbin的想法。
用js+xml构造一个成熟的框架，需要挺长的时间，如果封装的不好，
还会出现代码难以维护的问题。
维护js是十分困难的，我们公司跟别的公司开发一个b/s系统，
报表是jreport,通过url访问，然后用js封装一下，
结果呢，有些电脑用http://name访问erp出报表，有些机器则需要通过ip，有些机器则都不可以，有些则都不可以。如果直接访问jreport server则没有问题。
他们也检查不出什么问题。我看过源码，只是简单的转发url而已，
真不懂为什么这样。

Flash来实现Rich Client是一个很有意思的想法，我们在2001年的时候做的一个监控网络节点的软件中应用到了Flash。当时是用Flash做一个图形监控界面，嵌入到浏览器里面。Flash里面有很多小圈圈，每个小圈代表一个网络节点，圈的颜色代表节点是否Running状态，圈之间会有一些连线，代表节点是否连通的状态。

对于网络的监控是这样实现的，Flash每隔一个时间间隔，例如30秒把当前的节点，节点之间的状态格式化为XML，然后把这个XML通过HTTP POST的方式发送给服务器端的Servlet。服务器端的Servlet解析XML，将该状态写入数据库保存，作为历史监控记录，同时从各个节点收集状态信息格式化为XML返回给Flash。Flash再解析XML，将各个节点的信息，包括坐标，状态，连通率之类的信息解析出来，渲染到界面上。

管理员可以通过在flash上面拖拉的可视化的办法来对网络节点进行操作，这些操作都会格式化成为XML，发送到服务器的Servlet，由Servlet解析后，再执行具体的指令。

由于Flash的ActionScript具备良好的HTTP Client的支持和良好的XML支持，使得在Flash里面写ActionScript也是比较容易的事情，并且可以真正做到界面和代码相分离。由设计人员做好Flash，然后我们用Flash打开这个fla，在里面嵌入代码。这比传统的Desktop GUI的合作方式还要好，毕竟你不可能让美工用Delphi，Visual .net Studio来做设计，然而他们用Flash到是天经地义。

我是一直认为用Flash做嵌入页面中的动态交互图是比较好的办法，例如使用拖拉的方式定制工作流这些传统的页面不方便实现的可视化编辑，用Flash到是容易的很。