停止炒做，开始工作——评围绕 AJAX 的浮躁气氛

在js"组件"上投入太多恐怕会后悔.

js本身会发生比较大的变化  新版本对xml的支持会更好.  还有浏览器方面也会有新的情况出现. 比如在浏览器上集成一个轻量级的server. 有不少人认为可以将微型的cocoon集成到firefox上用来改进完善AJAX的构架. 现在这两方面是变化最快的时候 而且根本无法预测.   再这段时间积累js组件肯定是不明智的.


firfox在瘟上也只有4M多 为什么非要用IE浏览器 ? 如果要考虑普及的因素为什么还要坚持rich cilent ?

公司为一两个客户的需求 而走上畸形的技术道路是很危险的.

xuxj 写道:


对不起，我从不认为封装良好的组件是可以被业务直接使用的。当然，如果你的公司从来只开发一类业务的话可能是个例外，我认为开发人员永远无法预期用户希望如何使用一个界面组件，用户的思维绝对比程序员跳得更快更远，因为它不受任何技术上的约束，所以我采取的办法是依次满足用户的每一次过分的要求，它想象中的界面下一步会跳到哪里，我就跟他到到哪里，直到他跳不动或是不好意思跳了为止。所以，没有一个组件是可以让我满意的，因为它不会让我的用户满意。其实这里面的道理很简单，就象没有任何一个封装良好的MIS系统可以直接为企业使用的一样。所以我会使用最简单的input、button、tree......跟着用户一起跳跃。XMLHTTP使能了这种方式，其实并不累。


恕我愚钝，没能理解你说的这话的含义。如果我回答说将交互信号先在服务器端用JAVA进行调制，浏览器接收后再用JS进行解调，不知这样的回答可否让你满意。



你确信我们说的是一回事吗？

to xuxj：
我向你指出一点，在 Web 表示层基于组件的开发不仅是可能的，而且是必要的。我不是有个不成熟的想法来征求谁的意见，实际上这正是我们过去两年来的开发方式。基于组件的开发是提高开发效率，降低开发成本的必由之路。当然，是否能设计好一个表示层组件是一件有很大难度的事情。各种组件例如 tree、menu、分页如何设计和实现才是最好的方式，也是我们以后需要讨论的问题。但是你不能从根本上否认这个方向。基于 AJAX/XMLHTTP 的开发，如果没有丰富的组件的支持，至少在开发效率上，就没有办法和 Flash 相竞争。

给你一个建议，不要在自己没有做过一件事情之前，就轻易下结论说这件事情是不可能的。实际上我的很多同事或者朋友都开发过各种各样的表示层组件，相当程度上提高了开发效率。

找个靶子来批判一下，这个就是我所说的那类炒做文章：
Asynchronous JavaScript and XML (AJAX) with Java 2 Enterprise Edition
https://bpcatalog.dev.java.net/nonav/ajax/ajax.html
这篇文章里面的例子是相当初级的，就是 XMLHTTP 的一个最简单的应用。作者显然也是这方面的初哥。通过这个例子，完全无法看出 AJAX 在提高开发效率上（这其实才是 PM 最关心的问题）有些什么好处。我们 JavaEye 并不鼓励这种 Hello World! 式的创作。不要仅仅因为看懂了这个例子，或者写了一个比这个例子更好的实现就沾沾自喜，后面的路还长着呢。

如果 AJAX 仅仅就是 XMLHTTP，我可以说，我对 AJAX 是极度地失望。因为我在 2 年多以前就已经熟悉了 XMLHTTP，AJAX 并没有带给我任何的新意。以后我会给大家找到一些真正有趣的东西，大家来看看。

我想说的是什么呢？你们炒做可以，但是拜托请你们不要恶炒，否则本来是一个很好的东西，也有被你们炒烂的危险。

非常同意这句话。有的时候根本觉得没有办法积累出现成的组件，天知道客户什么需求。也同意dlee老大这句。应该提供那种可灵活扩展的组件。如，在用swing的时候（觉得组件库已经够丰富了，不知有没有胜过flash），可是还是有满足不了需求的时候，幸运的是swing提供了这种灵活性，以便你得到想要的组件（只是举个例子）。可是我觉得，企业本身基于组件的开发积累可能更加重要，主要的在开发方式上的经验积累。

DLEE你好，谢谢你指出的那一点，不过我想不管你是不是来征求意见的，大家都应该可以表达自己的意见，说说自己的经验和看法。首先声明一点我并不排斥WEB表现层组件的使用，如果有好的、适用的组件我会非常乐意去使用的。我想说的是很多情况下我们不应该过分地依赖于那些别人封装好的组件，因为相对于用户那些天马行空式的需求，它们往往显得过于僵硬而不够好用，如果我们很好地掌握并理解了最基本的XHTML控件组合JS和XMLHTTP的用法，其实自己完全可以做出更有创造性的交互方式，给用户以好的使用体验。我经常使用的XLOADTREE，但我不得不经常根据用户的要求给这个TREE上挂上不同的果果，比如radio、checkbox等等，这些都是XLOADTREE本身所没有的，不知道这是不是叫使用WEB层组件。有时候用户会希望datePicker中带有时间选择，有时候又不要。在sortedTable或Grid中，有时用户会要求加上分页，有时候会要求页面内排序，有时候又会要求跨页面排序或多重动态排序，我发现所有这些需求很难用一个封装好的组件来满足，一些看上去很炫的组件在使用时往往都必须要进行改写，有时候这种改写是值得的，有时候还不如我自己用Table\Tree\Radio\Button\Select。。。。。去拼出来。

使用XMLHTTP技术来构造WEB应用程序界面其页面效果和功能一点也不会比SWING、VB界面差，因为除了可以使用类似于SWING、VB等组件以外，还可以有更灵活的XHTML、CSS、JS等编程方法，但关键是这种灵活性是有代价的，你必须去学习这些方法，而不是只想着去配置一些组件，如果只想着用组件搭出来一些应用，那完全应该去选择XUL或XAML，或者Taglib甚至Applet，没有必要去学习什么AJAX或是XMLHTTP。

DLEE你真厉害，一眼就看出我没做过这个事情，这样吧，不如你将你常用的组件列出来，我们来一个one-by-one discussion如何？

呵呵，会有这个机会的。等我们将来发展这套 AJAX 组件库的时候，其中的每个组件都需要经过严格的考察。你也要倒出点真货才行啊。

基于组件的web开发当然是可能的，可以看看一个commercial 的ajax实现：www.backbase.com，其用自实现的BXML来定义组件，包括：


等功能，而且可以自己扩展这些component。

我记得还有一个支持AJAX得JSF实现，如果将来有了ide支持，开发效率不见得比不上flash。

to xuxj：
使用组件对提高开发效率是显而易见的,而且组件的多少好坏以及开发组件的难度决定了这种开发方式是否能普及.
tapestry,jsf都是很好的例子.
我对ajax的理解很很简单,在技术上和提高效率方面没有什么吸引人的地方,唯一吸引我的就是用户体验要远大于普通页面编程.

youcai,你好，可能你还没完全明白我的意思。我不是说组件不好，但如果某个组件在使用时让我不得不将界面的效果、内容、功能这三者混合在一起，我会坚决地弃用这个组件，我所写的界面严格地由三个部分组成，分别是.css,.jsp(按xhtml标准)和.js，我不细说你也应该明白这三个部分都是干什么的。我要说的是这三个部分的内容几乎完全不会重叠，我今天在修改一个界面的CSS，调试时整个界面的布局被我弄得颠三倒四，可是页面的功能却一点也没受影响，每个按钮都响应，每个交互功都完全正常地工作着。我通过修改CSS一步步地逼近我理想中的界面效果，在这个过程中我感觉很愉快，我以前用过很多组件，可是记忆中没有这种愉快的感觉。