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

XMLHTTP简单吗？在没有普及的框架前提下，他肯定是最困难的一种，因为你需要完全的在客户端用Javascript，在服务器端用Servlet进行XML的解析，构造。这相当于构造一个基于XMLHTTP技术的框架（这套框架包括服务器端和客户端两个部分），在没有这套“成熟”的框架的前提下，贸然的用XMLHTTP，是风险最高的方式。并且在客户端用Javascript进行XML的解析，操作DOM树，数据量一大，性能就是一个大问题。

从任何现实的角度来说，XMLHTTP都不具备普遍使用的条件，除非你们公司愿意帮把你们那套基于XMLHTTP的框架开源出来给大家用。

说到曹晓钢想做的框架控件，我到建议他转向用Tapestry

robbin，我完全不同意你的观点，你没有实践过，就不要轻易说这样的话。其实用 XMLHTTP 建造一个轻量级的框架是相当容易的事情。

那好阿你构造一个开源的XMLHTTP的框架出来，而我用现成的Webwork，拿一个简单的应用来，我们各自用自己的方式来实现一把，代码都开源，你看看谁的方案TCO低，谁的ROI高，如何？

我不想浪费时间来做这件事情，XMLHTTP 的应用在网上有很多例子，而且用起来很简单。XMLHTTP 可以带来更少的 B/S 间的交互，这个是现有的这些技术完全依靠服务器端的能力很难做到的。浏览器端的技术对于建造 Rich Client 肯定是有必要的，如果完全不同意 Rich Client，就根本没有什么必要再继续讨论了。

XMLHTTP 是 M$ 一个很好的创造，简化了 Web 层的开发，受到程序员的欢迎，以至于 Mozilla 也要去实现这个私有的特性。基于 XMLHTTP 可以做很多的事情，这种架构其实和 Web Service 已经没有多大差别了。

网络上的例子看看还行，真要做项目，里面有很多的困难需要花时间去解决。 XMLHTTP没有一个框架来系统的解决这些问题，是没有办法做为一个通用方案被普及的。我不觉得花时间做一个开源XMLHTTP框架是浪费时间，可以造福大众嘛，还可以就框架展开XMLHTTP解决方案的培训和咨询嘛。

回过头来说XMLHTTP技术，他是可以带来较少的交互过程，但是与此同时，它带来的是更多的服务器端和客户端本地解析，构造XML的复杂度，特别是客户端用Javascript来操作XML DOM树，我相信不是很多人都可以搞得定的，当然如果有一套成熟的开源框架的话，这个问题才有可能得以解决。

我不是说XMLHTTP不好，也不是说Rich Client不好，我只是说在现有的客观条件下，这个客观条件指的是没有一个成熟的开源的XMLHTTP的前提下，基于XMLHTTP的解决方案他注定就不可能成为通用普及方案。

就好像我们讲ORM，在没有Hibernate这样的开源的ORM之前，你就算知道对象化的设计持久对象这样做会节省很多系统的复杂度，提高很多系统的灵活性，但是你不可能要求每个人都去花钱购买TopLink，于是ORM就普及不了，而Hibernate一出，ORM立刻像雨后春笋，到处都可以看到采用ORM的软件了。

所以说一千道一万，如果没有一个成熟的开源的XMLHTTP框架的话，这种基于XMLHTTP技术的Rich Client就根本不可能成为一个通用的解决方案，因此也注定不会进入我的选择范围之内。因此当前的软件行业的技术发展阶段来说，也只能是Thin Client。

这个观点我接受。其实以前曹晓钢就想过只要在两端各封装一下，就可以把 XML 的复杂性对用户完全屏蔽起来的。可以自己定义一套 DTD 或者 Schema 和请求响应机制，这些事情在我看来并不是很难，不过对于普通开发人员确实难度大了一些。所以现在 XMLHTTP 还是只能用在比较少和比较简单的场合中。

不过我想 JavaEye 有能力建造这样一个框架的人不在少数。至于性能，我们以这种方式做开发做了好几年了，对 M$ 的 XML Parser 的性能非常的满意（以前我跟晓钢说过，M$ XML Parser 与所有这些 Java XML Parser 的性能不在一个数量级上），而且我们有一套很理想的后台（服务器端）分页机制可以减少大数据量的情况。

我没有时间去建造这样一个开源的框架，不过如果有谁对这些技术感兴趣的话，我非常愿意在这里做免费咨询的。

看到这我感觉对Robbin有点意见了，其实你可能还没有抽出时间真正地去尝试着做一下你上面提出的使用XMLHTTP的组合，就去反对他。我相信DLEE写的都是经验之谈，而不是在这里妖言惑众，你描述的你擅长的的解决方案是你的经验总结，我想DLEE描述的同样的他及他们公司的经验。我使用过STRUTS和WEBWORK作过项目，感觉很头痛的是开发人员协作和大量的文件需要进行配置和管理。我现在使用你所反对的这套组合，说句不怕挨骂的话，我觉得使用这套组合开发人员甚至都不需要协作，在一个经过良好分析的系统中，我实现一个业务对象的CRUD操作功能，从数据建表到HIBERNATE再到SERVLET再到XMLHTTP再到JS再到HTML，我一个人半天时间就搞定了，还能抽空去抽两根烟。原因就是文件少了，开发真的方便，不管是SERVLET还是JS中很多方法都可以分离出来重用。事实上我经过一段时间的开发已经形成了一个较完整的开发框架，只是还未及将它描述出来。我现在的做法是一个业务对象使用一个界面（加CSS）进行CRUD（包括搜索、分页、列表显示、编辑、新建、删除、页面数据校验、服务器端数据校验、数据字典选项获取），配合一个JS和一个SERVLET，下面就是Hibernate了，感觉开发很流畅，除了在web.xml中配置一个servlet外，不需要其他任何配置文件。

没有打击任何人的意思，只是针对技术进行讨论，我想ROBBIN应该不会曲解我的本意吧。

DLEE，请教一下，这个东西是不是一定要MS的浏览器，还是FireFox有对应的技术，做一些包装、花一些时间两者都可以用

我对html+js没有什么信心了，用它来做好ERP这类的系统真的太难了，

我不反对XMLHTTP阿，我虽然没有实际的XMLHTTP开发经验，但是我对XMLHTTP的原理还是很清楚的，其实我对XMLHTTP的提出的问题很简单，上面已经反复强调过了：

1、你有没有成熟和完善和开源的Javascript来封装XML的框架
2、你有没有成熟和完善和开源的的Servlet来封装XML的框架
3、客户端数据量大的时候性能怎么解决？

你们谁能给我一个确定的答案？我问了这么半天，至今没有一个人给我一个正面的回答。我不需要一定做过项目才能提出评价意见，这些问题不解决，我就没有办法把XMLHTTP应用到实际项目中去。

回过头来再说，XMLHTTP只不过是取代HTTP POST FORM而已，他可以有效的减少和服务器交互次数，简化页面流程，但是浏览器端技术中最不好解决的实际上往往是这些部分：

1、批量数据录入
2、报表和图表的打印，表格的套打
3、类似Desktop GUI那种丰富的交互式界面

当前1和2都没有很好的解决办法，3也就是写Javascript而已。XMLHTTP的引入能够解决的问题都不在上面之列。因此XMLHTTP技术本身并不是一个完整的解决方案，只不过是整体解决方案中的某一个组成部分而已。而我关心的问题不是XMLHTTP所能够解决的。