继续jsf 和ajax的伟大发明

我对jsf优势的评价:
1.request生命周期的视图状态很好维护了
与业务逻辑无关的视图状态不应该保存在服务端，据了解JSF好像全放在session中的，如果这样的话，如果做高负载网站，消耗服务端内存比较多。
2.不需要从粗粒度考虑事件触发命令后由谁来做事情了
这一点我一直存在疑问，向您请教，页面上的事件触发，有相当一部分应该不需要服务端计算的，JSF对这种场景是否有封装和考虑。
3.验证机制的建立可以更好的组件化，复用验证包
要严格验证的话，服务端的验证包我也是认可的，但是改善响应速度的话，不需要查询持久层的验证应适当提前到客户端检查，验证机制的组件化目前各框架都是有的。
4.对象，数据转换问题得到了较彻底的解决。
数据转换也都是有的，不知道您说的彻底如何定义？
5.标准组件标签可以很好holder及update输入的数据
请教JSF的holder数据是存放在哪里的？
6.可以为某一个按钮加入无限多的监听调用程序或组件
这个EXT也支持的，也是用像Java的监听机制的。
7.可以和seam集成，免除了很多不必要的配置，降低了硬分层带来的开发负担。
这个是后端集成的问题。
8.可以和spring集成，共享spring ioc bean
这个一般MVC框架都支持。
9.通过seam或者spring可以加入更富有规则的跳转机制，或者基于xpdl的状态调整
跳转机制的问题，Ajax为主设计的话，跳转不是很多，也不是以跳转为主。
说起来也谈不上是Ajax的特色，如果客户端UI交互能改变习惯的话，比如接近于CS结构的操作习惯的话，操作就不是以页面跳转为思维导向的。
10.自己开发的组件终于有一个根可以依托了.
还是认为JSF自己开发基于Ajax应用组件的调试成本比较高。
11.很多优秀的视图组件，比如树形等都可以很快获取到。
视图组件一般都有的，客户端框架的特例如EXT已经做到像素级的渲染效果。
而且客户端为主导的话，页面上上的组件进行互相之间的交互（非安全性高的，主要是显示调整上的）应该是有优势的，我不清楚JSF的JS组件能很方便的互相交互，操纵页面上的各元素的位置、布局、大小、颜色么？
12.表现层终于可以使用pojo方式进行设计开发，充分享受OO机制带来的灵活和弹性


ajax 来自 icewubin 的观点:

这个POJO范围有点大，目前的如EXT框架，也是OO的，而且方法天生就是OO，操纵方法非常灵活，比Java还灵活，当然应为JS不是强类型，编译检查和IDE支持程度是不如Java的。
以Ajax为主的话，大致思想如下，您先静下心看一下：
服务端的Controller层（弱化了，也可以叫Facade层，封装业务service的）的主要责任是为和客户端通信提供便利。我认为的便利中主要有一点是对Hibernate的加载范围或者说POJO的对象导航图的范围界定边界。有工具可以直接转换成JSON字符串，也就是JS认可的对象图，客户端拿到后也是比较OO的。
如果传统方式（不是Ajax）的话:
根据POJO编程，生成需要的组件，然后最终都是servlet写成html页面传到浏览器，再显示出来。

但就这两种方式比较的话，肯定是服务端为主的效率高一点，客户端负责显示的方式效率目前也不是很差，但肯定是比不过以服务端为主的方式。

但是之前提到过，以客户端负责显示为主的方式，可以减少用户等待时间，减少不必要页面切换带来的网络流量，减少页面互相切换带来的URL转换的逻辑复杂度。当然我认为即使有了这些好处，开发效率上可能还是JSF效率高，但是功能不一样，用户的体验改善程度和显示程度效果不一样。

所以我一直认为这两者的比较在目前阶段往往就会变成非技术原因的主导，这也是我为什么说了这么多“没营养”的言论，是这样引出的。

首先是需求上是否需要这些效果，如果不需要或者可以引导客户的话，那就是人为的制造需求了。

但是认为制造需求（面子工程）在打单和竞争激烈的竞标项目中还是非常重要的。

js和jsf通过对象交互基于JSON转换，最多转个entity就了不起了吧！我可不相信监听操作也能转换，那么只是基于数据方式多了一点对象感觉，与其这样不如使用xml分割，对两边的处理都能更灵活一些！

这里的效率指的是...

以Ajax为主的话，大致思想如下，您先静下心看一下：
服务端的Controller层（弱化了，也可以叫Facade层，封装业务service的）的主要责任是为和客户端通信提供便利。我认为的便利中主要有一点是对Hibernate的加载范围或者说POJO的对象导航图的范围界定边界。有工具可以直接转换成JSON字符串，也就是JS认可的对象图，客户端拿到后也是比较OO的。
如果传统方式（不是Ajax）的话:
根据POJO编程，生成需要的组件，然后最终都是servlet写成html页面传到浏览器，再显示出来。


这是icewubin的观点. 应该指的是开发效率

弱化服务端的Controller层目的是将控制交给client来完成，自然会导致大量的数据转换，对象结构的复杂性是不容易跨技术领域复制的，自然会带来更多的不同技术机制间对象的重复和维护！

数据转换以目前最近我们公司的一个成功项目来看，基本是工具的事情，开发效率还好，而且因为用了JSON，其实是比XML少了一层转换工作的，因为JSON到客户端已经是默认的JS认可的对象了。所以对象结构的复杂性这一点来说，我们使用了点技巧（自己写了个简单的递归工具类，精确控制对象导航）屏蔽了，开发效率和可读性都还好。

你说得很对：“自然会带来更多的不同技术机制间对象的重复和维护”，只是没有你想象的那么多。
1.对象在客户端和服务端的重复，重点不同，重复性不会带来什么问题，客户端以展现为主，服务端除了少量的为展现服务，大部分还是pojo，服务端和传统方式比是差不多工作量的，维护么，服务端基本无状态，除了特殊需求，主要是客户端维护当前状态，这部分是相对复杂的，充分利用EXT可以屏蔽不少维护工作。
2.第一帖中提到过：UI交互模式上来讲，就是因为客户端承担的工作的增加，加以利用可以在某些方面极大的减少开发工作：“减少页面互相切换带来的URL转换的逻辑复杂度。 ”
具体举一个例子：利用多标签，把原本URL跳转的工作变成了新开标签的方式，减少了新开页面中的返回逻辑，减少这两个页面的导航栏的应用，减少两个URL切换带来的表单回填的工作量，同时改善用户体验：方便迅速的来回看两个标签网页的内容。
之前还举过其他例子，也就是根据具体业务分析，根据EXT的特色，才考虑开发模式下哪种方式更方便，可以充分利用已有条件，在很少的开发量的基础上，既增加效果，又减少开发量（减少页面数量，减少页面切换逻辑，减少表单回填次数，减少导航栏的应用次数，减少服务端代码量，如客户端页面减少的得多的话，客户端的代码也未必会增加）。

至少在我最近实践的一个项目里，从UI交互模式上引导客户，带来了开发工作上的非常巨大的收益，整体开发效率是显著提高的，维护成本也大大降低。当然前提条件比较特殊，客户本身对界面需求不明确，对新的UI交互模式也没有明确的概念，客户对我们的建议也比较认可，没有出现不理解而故意刁难的。

所以我也知道这些好处很难推广，也很难说清楚到底节省了多少开发成本，但是至少是一个很实在策略。

真是受不了这种满大街跑的常识错误 XHR的名字告诉我们 那传递的东西一定是XML 即使它只是一个TextNode
JSON用于对象序列化 不是数据格式- -！

MicroSoft的名字告诉我们，那个公司一定又小又软...

又要陷入口水之争。。。建议没有ajax经验的同学不要随意发言。

fins的帖子已经锁了，再争也没什么意思，新帖不如专门讨论如何更好的实现B系统、S系统。

依稀见到了当年 java vs .net 的影子

其实不应该再围绕jsf来谈论
可以如 leebai 所说, 讨论一下如何实现如何设计b/S系统中的 B端 和 S端也许更有意义.
那些喜欢JSF的人,如果最后能够证明"JSF可以帮助我们构建拥有优良设计的B/S系统"的结论的话,那么你们可以继续放心大胆的使用.

而不喜欢JSF的人,如果最后能够证明"基于JSF构建出的系统不具备B/S系统应有的优良设计"的结论的话,那么你们可以继续放心大胆的鄙视JSF.

但是问题的关键是, 要先把"B/S系统应具有哪些优良设计与特点"先讨论清楚.

我先起个头:
企图抹平B/S界限的做法往往是不正确的.因为不应该抹平,而且也抹不平.

啊，谁说JSON只用于对象序列化？JSON在服务端就是一串文本而已，我间接调用的JSON-lib可没有生成任何的XML结构的东西，服务端生成的JSON文本直接写到response里的，不做任何处理的。

我们在调试的时候有时候也会在地址栏里直接打Ajax请求的url，拿到的就是JSON文本，从未看到什么用XML封装的迹象，你这也太搞笑了吧。