rich Client的话题

dlee的话


   我赞成前半段，但反对后半段。

  在这里说一句算是先留个话。

  呵呵，dlee,我是XMLHTTP的反对者。

  只是最近琐事众多，需要等段时间再和你好好摆龙门阵。

  我也是在做rich Client的，技术和
http://forum.iteye.com/viewtopic.php?t=8921 这个帖子里介绍的差不多。而且我们的框架已经相当成熟了。

  无论国内国外很多公司都想确定将来rich Client的技术主导地位。我们也是，虽然我们公司不大。

  稍微等等，我也要为我们的思路说说。到时候一并做个多种技术的比较吧。

好的，等待你的文章。我最近比较忙，经常往返于上海和杭州两地。等项目不太紧张了，大家在杭州聚聚。

XMLHTTP 其实只是前后台通信的一个很小的功能，非常的简单，实在没有什么必要坚决反对或者坚决支持（说实话我比较讨厌 100% pure xxx 的人）。我们已经在 Gmail 等应用中看到了大量使用 XMLHTTP 的情况。

我真正反对的其实是 HTML FORM，而不是 HTML 本身。不谦虚地说，我现在对 HTML/XHTML/DHTML/CSS/JS/XMLHTTP 这些技术的掌握已经达到了专家的水准，至少一年之内，我还是要指望着这些技术吃饭的。对于 HTML FORM 的缺陷今年 3 月我已经在 JavaEye 的讲座中说明过了，这些看法至今也没有变化。我在 XWT 的 FAQ 中看到其作者持有和我完全相同的看法。我一年多以前曾经认为 Java 表示层开发如此困难，问题是出在 JSP 身上。这种看法并不完全，其实问题的根子是出在 HTML FORM 上面。
FORM 并不适合复杂的交互模型。FORM 最初的设计就是为了简单地请求一个静态的 HTML 页面，所以才会出现立即切换到另外一个页面，将所有内存中的对象全部废弃的这种 "one size fits all" 的设计。它本身仅仅是为了完成这个简单的任务而设计的，但是现在 FORM 承担了太多它力所难及的复杂任务了（mission impossible），甚至成为了 Web 表示层交互的核心，这就很成问题了。当然 FORM 后来添加了 target 属性，可以把 target 设置为一个页面中不可见的 IFrame 来解决这个需要切换页面的问题。即便是这样，正如以前这里的一位网友所指出的，FORM 还存在着一个缺陷是通过 FORM 获取的数据只能通过异步的方式得到（因为数据是在另外一个页面或者一个 IFrame 中），很不方便，这增加了交互设计的复杂性。而且通过 FORM 获取数据只能通过在后台设置页面中的 Hidden 字段值的方法，处理起来同样很不方便（awkward & ugly）。FORM 所提交的数据都是简单的字符串格式（param1=value1&param2=value2...），无法描述具有复杂层次关系的数据，因此 FORM 并不适合前后台交换复杂的数据，而描述具有复杂层次关系的数据恰恰是 XML 的强项。FORM 也并不适合提交和获取大量的数据。
由于 FORM 所存在的这些明显的缺陷，所以所有基于 HTML FORM 的表示层技术我全部都不看好，包括 JSP/JSTL/Struts/Webwork 等等。即使是一个基于 HTML 的 Rich Client 框架也肯定是需要完全抛弃 HTML FORM 的。那么还有什么技术呢？只有 XMLHTTP 这棵最后的救 命稻草了。JSP 其实并不比 ASP、PHP 甚至 ColdFusion 差很多。但是现在看来，ASP、JSP、PHP 这些技术都落后了。但是落后的技术是不是就是没有用处的技术呢？千万别这样想。看你以前的知识积累和你要做什么事情了，只要能以很低的成本满足用户需求的技术我认为都是有用的技术。最近在 MSN 上见过我的人都知道我现在的 title 是：
用户需要什么？用户永远不需要技术！
这句话具体的含义我们以后再说，大家不要断章取义。

至于你反对的表示逻辑完全放到前台运行，或者一定要以 XML 技术为核心，这种趋势在我看来已经是非常明显的了，对于你的反对意见我非常感兴趣。

我接受了 robbin 的看法即 JS+XMLHTTP 只是一种过渡的方案，但是完全不同意他对于 JS 命运的判断。我现在比较感兴趣的是 XWT 这个项目，其架构和 XUL 是很相似的。我相信这个项目代表着一些更先进的东西。

Good luck!

呵呵，有机会一定拜会一下dlee大哥哥。

各位大哥大姐：别吵啦，在技术上没有谁对谁错，只是什么技术适合而已。
dlee：
不如开个xmlHTTP + js 方案的设计的讨论吧，以前的帖子都是讨论这种技术好不好的东西，而没有好好讨论一下基于这种技术的设计方案，不介意的话可以把你们现在的表示层的框架拿出来讨论一下，如果不保密的话。

to robot_liu：
等着看 femto 做的那个开源的框架吧。主要用了这些技术：
JS+XMLHTTP+Spring+Hibernate
其实说实话我们的这个框架虽然很好用，开发过程中也积累了不少经验，但是在设计上还是存在着很多不足的。而且和我们后台的设计绑的很死，不是我贬低你，其实即使给你看了，你也看不懂的（除非把我们后台相关的代码全部让你看一遍），而且对你也未必会有很大的帮助。
不过在现在这个阶段 HTML 仍然是主流开发技术之一，这样一类框架还是很有帮助的。毕竟会 HTML、JS 的人很多，成本也是很低的。所以我们应该多支持 femto 来把这个框架继续做下去。

如果仅仅为了学习，多看看 XWT、XUL 这样的框架我相信会有更大的帮助。

我们正在酝酿的开发平台最新的 3.0 版中表示层技术将发生非常大的变化，我们将会评估 XAML、XUL、Flex、Laszlo、XWT 等等技术。比较可能选择的是 Flex 和 XWT，因为它们都是可以完全跨平台的。

“ 有人说我这一年来过分重视表现层的技术，放下这个分歧不说，抛开客户端表现层的技术不论，就c/s或b/s之间的数据传输方式，我现在能看到最有前景的就是webservice，CORBA,RMI,EJB,DCOM,webservice等等数据接口形式广义上讲都是rpc模式，它的好处很简单：模块或系统之间的接口定义：形式简单，语义明晰，面向对象（构建）！而这些之中只有webservice是跨平台且跨语言的。而就目前看，由于html的表现力丰富，技术成熟，应用广泛，所以基于dhtml+xmlhttp+jsp / webservice 的rich client组合将在未来几年之内都被看好！”

这是一位我比价佩服的同行闲聊中对我说的一句话，在这个问题上，他与我和dlee的观点是一致的。他曾经写过一个js framework，好像为的就是这个。

口气不小啊！你就不怕哪天让高人看了，说你不知天高地厚！哈哈！

呵呵，不班门弄斧，怎么能引的来真人呢？

我也在做下一个版本的项目计划，重点也是表现层的改变。
dlee能说说评估的标准吗？我个人认为开发足够rapid70%+用户体验30%就可以。所以一直在研究Flex。XWT也有看。其实代码写起来差不多的。
很不爽的是，公司没有人赞同也没有人反对。想跳槽了

经过几次重大的重构，我感觉我的RIA框架已经相当成熟了，使用起来也越来越顺手。我把之称为一个表现层的依赖注射框架。利用这个框架可以以配置的方式启动一个项目的界面开发，而把项目中的功能性界面以配置的方式部署到系统中去。完全分隔开了界面开发和后台开发的工作。现在的VIEW是用JS＋HTML实现的，通过对界面与后台的交互过程进行完全彻底的封装，利用这个框架如果转换到别的VIEW开发技术后台可以完全不用作任何修改。很有成就感啊，呵呵。