Java Web层的下一个王者是谁？

也不算太复杂，个人感觉规范定义的还是很清晰，只不过实现的机制比较欠缺而以。

JSF对于Ajax的集成根本就没有优势，反而会限制Ajax技术的发挥。JSF对于Ajax的集成仅仅适用于一些非常简单的交互模式，复杂的DHTML组件通过JSF集成用起来非常别扭。

Ajax客户端框架yui-ext、Prototype、Dojo等等与Spring IoC集成都是非常容易的事情，可以构成一种Ajax+REST的架构。非要在中间加一个JSF框架，强迫开发者必须通过JSP tag来开发Ajax功能，完全是多此一举，吃饱了撑的。开发JavaScript并不像某些人宣传的那样是一个地狱，这样宣传的人是别有用心的。

别光听宣传，自己去用一下，OK？

这几天看了一下struts2 立即决定丢掉struts1.2
早知道webwork这么好用 早就用webwork了
但是为什么webwork一直没能战胜struts呢
还是因为struts在早期占据了大量的市场 导致webwork很难杀进来

我觉得靠struts1的强大基础 struts2在未来一段时间内还会是web层的王者

JSF拥护碰到不少 纳闷

现在想玩webwork了 不知道好不好 对jsf真的没什么好感

struts1.X 由于遗留系统太多, 还会继续有市场,

JSF 是SUN,IBM,Oracle等几家大型厂商公共制定的一个JSR, 是个标准


Java Community Process(JCP)制定的Java Specification Requests(JSR) 127 - Java Server Faces(JSF)( http://www.jcp.org/en/jsr/detail?id=127) 就是一个基于JAVA技术的Web应用框架标准，同时也是对于J2EE标准的一个重大补充。JSF使得您能够轻松而方便地设计开发基于JAVA技术的 Web应用，同时所开发出来的应用也会非常易于维护、重用和扩展。 JAVA/J2EE业界普遍认为JSF将会在不久的未来取代目前业界非常流行的Apache Struts框架。



有一个事实非常有趣，Apache Jakarta Struts框架的作者Craig McClanahan同时也是JSR 127 JSF项目的两个领导人之一，这似乎保证了未来两种框架之间的易迁移性；那么再从应用开发的角度来看的话，Struts和JSF两种框架也有很多相似之处，比如就像Struts框架一样，JSF也充分遵循MVC设计模式，也定义了一整套JSP标记库来生成与JavaBean属性绑定的HTML元素，也定 义了相应的组件导航模型等等，接下来，JSF这个即将出台的新标准将会成为J2EE的一部分，而目前业界所有的J2EE应用服务器，不论是免费的还是商用 的，以及相应的开发工具都会正式公开对于JSF的支持。从以上两点来看我们有理由相信，在不久的未来，把已有的Struts应用转向JSF将不会存在很大的困难。

对于没有使用过JS的Java开发者来说,开发JS会很容易吗?
在AJAX火的时候,一个同事曾经第一时间买了那本中文的 AJAX 书,
看完后,对我说,"如果有替代的产品,再也不自己写JS了,太痛苦了"
我自己也简单了看看那本书,确实,和开发java来说,一个天上,一个地下.

jsf对AJAX的集成,就是关注在一些普遍,简单的ajax功能上,让开发者可以不用写任何js代码就可以开发出ajax功能从程序,这其他东西可以实现吗.

看看这里的ajax demo示例, [url]http://livedemo.exadel.com/richfaces-demo  [/url]
不用写js代码 就可以轻易实现这些功能,这难道不是工业化生产所需要的吗.

但是,有些开发者喜欢写js,这属于个人爱好, 就没办法了. ^_^.

开发JavaScript并不像某些人宣传的那样是一个地狱

瞧把你给美的，ASP.NET Ajax早就可以做这些事情了。
而且JSF给Ajax造成的紧耦合，事件模型和状态存储与服务器的严重绑定，这些是不能不考虑的。
给你一点甜头你果然就上钩了。

如果能够出现一套杀手级的AJAX平台，特性包括类Delphi的界面定制，简单的JAVA SERVICE调用，内建的安全机制，那么这个玩意会成为新王者，而JSF就不用存在了，而struts2还有生存空间。
毕竟操作监听器这种东西天经地义就应该放在客户端而不是放在服务端的。服务端只应该处理service。

标准可能会被服务提供商提供 未必会被开发人员接受
ejb2不也是标准吗，还不是被hibernate打垮
这些标准只不过是垄断市场的手段而已 影响不了业界的方向