继续jsf 和ajax的伟大发明

我没说自己懂啊....... 这跟自大有什么关系啊......

啊，那我理解错了，但是懂也分很多的，扣字眼了！

怎么没有懂JSF的人出来说说伟大的发明跟JSF的关系呢

这个得问始作俑者fins，我觉得他的那个两头勺子确实不算什么发明，人们之所以不那样用，是因为嫌手不卫生！
如果非要那样想问题，我也发明一个勺子，一个手柄，下面有两个头，一个是叉子，一个刀子，还比较卫生,感觉ajax现在不就是这样子吗，客户端的事情想全包，服务端的事情也想在它那里做，都平级到client去做！

你“发明”的是简单版的“瑞士军刀”啊？

我对jsf优势的评价:
1.request生命周期的视图状态很好维护了
与业务逻辑无关的视图状态不应该保存在服务端，据了解JSF好像全放在session中的，如果这样的话，如果做高负载网站，消耗服务端内存比较多。


jsf可以配置状态在客户端还是服务器端维护，一般在客户端

2.不需要从粗粒度考虑事件触发命令后由谁来做事情了
这一点我一直存在疑问，向您请教，页面上的事件触发，有相当一部分应该不需要服务端计算的，JSF对这种场景是否有封装和考虑。

这个可以的，本来jsp就是这样的，jsf保留了jsp的所有特性。

3.验证机制的建立可以更好的组件化，复用验证包
要严格验证的话，服务端的验证包我也是认可的，但是改善响应速度的话，不需要查询持久层的验证应适当提前到客户端检查，验证机制的组件化目前各框架都是有的。

可以实现客户端验证，传统的客户端验证方式还是可以用的，validator是个鸡肋

4.对象，数据转换问题得到了较彻底的解决。
数据转换也都是有的，不知道您说的彻底如何定义？

定义了converter，可以静态和动态配置。基本的类型都已经实现。基本够用。
这个ms是跟beanutils学的。

5.标准组件标签可以很好holder及update输入的数据
请教JSF的holder数据是存放在哪里的？

你可以holder在你想holder的地方，默认是viewstate，在客户端，这个是跟asp.net学的，名字都一样。

6.可以为某一个按钮加入无限多的监听调用程序或组件
这个EXT也支持的，也是用像Java的监听机制的。

这个就是一个observer模式，没有什么东西

7.可以和seam集成，免除了很多不必要的配置，降低了硬分层带来的开发负担。
这个是后端集成的问题。

seam是怎么出来的。

8.可以和spring集成，共享spring ioc bean
这个一般MVC框架都支持。

这个是spring的无入侵性决定的，可以广义的说任何java程序都可以与spring集成。

9.通过seam或者spring可以加入更富有规则的跳转机制，或者基于xpdl的状态调整

跳转机制的问题，Ajax为主设计的话，跳转不是很多，也不是以跳转为主。
说起来也谈不上是Ajax的特色，如果客户端UI交互能改变习惯的话，比如接近于CS结构的操作习惯的话，操作就不是以页面跳转为思维导向的。

跳转机制和struts有点像，但是可以自定义跳转机制的。

10.自己开发的组件终于有一个根可以依托了.

还是认为JSF自己开发基于Ajax应用组件的调试成本比较高。

可以从实现了ajax的JSF框架入手，比如richfaces和icefaces。
简单，调试的成本也许比ext低。

11.很多优秀的视图组件，比如树形等都可以很快获取到。
视图组件一般都有的，客户端框架的特例如EXT已经做到像素级的渲染效果。
而且客户端为主导的话，页面上上的组件进行互相之间的交互（非安全性高的，主要是显示调整上的）应该是有优势的，我不清楚JSF的JS组件能很方便的互相交互，操纵页面上的各元素的位置、布局、大小、颜色么？

jsf上可以保留jsp或者说是dhtml的几乎所有的特性。

12.表现层终于可以使用pojo方式进行设计开发，充分享受OO机制带来的灵活和弹性


这个我不敢苟同，很多复杂的实现我们还是前后台不分家的。无奈啊。

jsf的精华是组件化
事件机制是基础
web程序界面相关的技术数量众多，组合繁复，标准难以统一
随着界面表现的提高，逻辑和界面似乎联系得越来越紧密
目前实现组件化，提供逻辑和界面的无缝融合，隐藏与业务无关的复杂实现，是先进的也是无可奈何的思想
要学jsf最好也学jsf组件开发
jsf比struts难学但开发简单
上面是我的个人的一些想法