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

to swing：
分页显示数据是一个 Rich Client 框架最基本的功能之一。我认为是很合理的实现方式。你们需要耐心地向客户解释，而不是一味迎合他们的要求，那样你们就非常被动了。假设真的有 1000 行数据，你们把所有这些数据传到前台，其延迟以及随后所消耗的内存资源和对性能的影响都是无法承受的，难道客户连这个都无法理解吗？

我并不认为锤子和钉子的比喻在这里是恰当的，这里的问题是你们如何充分利用好这个锤子的问题。不管 JS、Java Applet、Java WebStart、Flex 我都不认为是完美的解决方案。不管用哪个锤子效果都是差不多的。

编辑 JS 我们常用 UltraEdit，下面这个编辑器也还算不错：
Antechinus JavaScript Editor
http://www.c-point.com/javascript_editor.php

XML 与 Java 并不存在什么竞争关系，而是珠联璧合的一对。

引用：XML 与 Java 并不存在什么竞争关系，而是珠联璧合的一对。

^_^   你没理解我的话，XML一统天下，不代表就把所有其它都扼杀啊，怎么说不是手下大将如云，个个能征善战的话它怎么可能君临天下？（希望讨论这种无聊的东西不会被禁止）

UltraEdit我感觉是比较好的东西，可惜啊可惜，
我讨厌它的一些无关紧要的东西，比如字符显示的效果，
看着不舒服，实在影响心情，^_^
我是比较情绪化的。
而用起来好像在一些方面没有editplus方便，当然，我知道它可以很容易做扩展，只是自己比较懒而已。（别扔我鸡蛋，确实，懒就不要嫌这嫌那的乐）

至于用户是不是有办法理解，他们还有其它更要命的要求，那就是要所有功能在一个界面都能完成。
关于性能，用户说，机器我们可以配，现在的性能不行换新的，关键是我们要好用。滚动条拖拖多方便。
其实我们也不是迎合，前面说乐，实在没办法乐。当然，其实这个跟很多东西有关，就不细说乐，因为讨论这个的话恐怕是没完没了。我自己也注意，以后不再提这个东西乐。
“用户永远是上帝！”
这个我是前段时间去过医院以后，回来对自己说的话。

引用：我并不认为锤子和钉子的比喻在这里是恰当的，这里的问题是你们如何充分利用好这个锤子的问题。不管 JS、Java Applet、Java WebStart、Flex 我都不认为是完美的解决方案。不管用哪个锤子效果都是差不多的。

呵呵，拿锤子找钉子我感觉是普遍存在的，
以前我老说，这个世界没有什么是绝对的，
有一天一个同事告诉我，你说这句话本身就是绝对。
所以，有时候换换角度看问题，虽然不见得就好，但是也不见得就不好。

不过说实话，我也挺不喜欢搞Client这边的，我还是倾向于Server Side的开发，Web Tie越薄越好，不想搞得太复杂，其实用XML比较好，不用特别关心叶面的东西

我看Webwork更喜欢看Xwork....抽象有搞头，我就喜欢:D

html+js实现的erp，在某些方面还真难用啊。
特别是财务方面，有很多公式的制定。
纯html交互性太差了。

刚开始我看好webwork，后来我觉得spring更强大实用，不过，spring mvc有点复杂。

其实xml对于上传文件一样可用，因为xml不单止可以描述文本信息，二进制一样可以。

采用xml有一个很大的好处就是可以方便地移植。

现在的框架对于V这方面的确是少考虑了很多，原因(我猜)，1：很重要的一点，就是写框架的一般都是程序员（写代码的，中国程序员除外），所以对界面不太熟悉。2：框架大部分是外国人写的，可能外国的分工比较清楚，界面追求没有中国这么刻薄。


关于web框架，我公司也打算只用spring（研究ing)，虽然有人说它还不成熟。

其实关于交互这种，或者改动频率很快（像电信的优惠XXX）的话，建议用动态语言（python,jython等）

Bindows 太复杂了，一个本来就很复杂的 Tapestry + 一个也很复杂的 Bindows，我并不认为这样的组合是非常理想的组合，现在为什么还是有很多人自己制作表示层框架（例如 fastm/fastm+）不是偶然的。

从普通 Java 程序员甚至系统架构师的角度，忽略浏览器端的技术完全合理。但是从一个产品总负责人的角度，是不可能忽略掉手边的任何一种技术的。正如以前我指出的，做好表示层开发想完全绕过 JS 是困难的。表示层两大问题：
表示逻辑与业务逻辑的分离
建造表现能力更强的 Rich Client

都必须要解决得很好才行。

噢，那你的意思就是说 Javascript + XML DOM parser + XMLHTTP + Servlet是很简单的，一点都不复杂的东西咯？

在我看来，我宁愿选择 Bindows + Tapestry 或者 Bindows + FreeMarker + Webwork这种成熟的框架，而不是什么都自己从头开始一点点来。

再说fastm也是类似FreeMarker的模版语言，和Bindows有啥关系？

对比如下选择：

Javascript + XML DOM parser + XMLHTTP + Servlet


Javascript + Webwork

你觉得哪个简单些呢？

robbin，这些组合用起来肯定是没有问题的，但是这些不同的框架设计理念上存在着一些差别，而且彼此的功能存在着重合，简单组合在一起未必能提高开发效率。

以前曹晓钢曾经在 blog 上考虑过用 XWork + XMLHTTP + JS 建造一套控件库（开发框架），我认为这是非常可行的一条路。其实 XML 的这些复杂性是可以以面向对象的方式封装起来的（幸运的是 JS 某种程度上也算是一种面向对象的语言）。而且我并不认为 DOM 和 XPath 是非常复杂的东西，经常用用就熟悉了。

XMLHTTP 的工作方式类似于 SOAP，它本身很简单，但是它是一种胶水，可以有效地把服务器端和浏览器端的技术结合起来。我从来也没有反对过服务器端的这些技术，只是说两者结合起来可以达到很好的效果。

我觉得我们现在自己的土制开发框架最简单，原因就是手熟。