|
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-07-08
qingyujingyu427 写道 看到一些回帖的人的观点都是： seam作为jboss的一个这么完美的开源项目，可惜啊，就是用了JSF这个落后丑陋违反潮流的东西。
不知道这些人有没有真正的了解够JSF， 估计是以前看论坛里各位大佬天天批判JSF，人云亦云，自己也没去了解也没有实践过就开始鄙视它了。 其实Robbin所说的seam的前4个优点都是由JSF决定的，任何JSF的实现都有这些优点。如果你想让seam不用JSF而又要保留这些优点，那只能让seam项目组自己去创造一个类似于JSF的标准而又要更先进了，看来seam项目组并不觉得这是一件简单的事情，或者他们觉得JSF很可以，总之他们没有去这么做。 个人认为，JSF非常适用于企业应用，如果你大多数的经验都是开发互联网的经验，那最好也就别来评判JSF了。 同意这位兄弟的观点，最近参加了一次QClub的活动，发现做企业级开发的人和做互联网应用的人，在思考问题的方式和想法上真的有很大的不同。Seam作为一个面向企业应用的框架，其设计思路更多的是考虑企业应用的诸多问题，所以需要大家在了解一个东西的时候，更多的应该先了解其定位。 |
| 返回顶楼 | |
|
发表时间：2008-07-08
springhill 写道 qingyujingyu427 写道 看到一些回帖的人的观点都是： seam作为jboss的一个这么完美的开源项目，可惜啊，就是用了JSF这个落后丑陋违反潮流的东西。
不知道这些人有没有真正的了解够JSF， 估计是以前看论坛里各位大佬天天批判JSF，人云亦云，自己也没去了解也没有实践过就开始鄙视它了。 其实Robbin所说的seam的前4个优点都是由JSF决定的，任何JSF的实现都有这些优点。如果你想让seam不用JSF而又要保留这些优点，那只能让seam项目组自己去创造一个类似于JSF的标准而又要更先进了，看来seam项目组并不觉得这是一件简单的事情，或者他们觉得JSF很可以，总之他们没有去这么做。 个人认为，JSF非常适用于企业应用，如果你大多数的经验都是开发互联网的经验，那最好也就别来评判JSF了。 同意这位兄弟的观点，最近参加了一次QClub的活动，发现做企业级开发的人和做互联网应用的人，在思考问题的方式和想法上真的有很大的不同。Seam作为一个面向企业应用的框架，其设计思路更多的是考虑企业应用的诸多问题，所以需要大家在了解一个东西的时候，更多的应该先了解其定位。 是的，我完全同意这种看法，企业应用架构的设计要求和互联网应用的架构设计要求完全不同。 在服务器端保存状态这是互联网应用的大忌，但是Seam这样用下来对于企业应用实现有状态的业务流程却看起来效果非常好。 |
| 返回顶楼 | |
|
发表时间：2008-07-08
Anatorian 写道 虽然已经用seam 做过一个应用了，但是还是觉得seam不够好，不满主要来自于JSF。不过做做简单的以表单堆起来的应用还可以，其它应用的话，用起来还是很麻烦。期待seam什么时候与 jsf解耦。
现在Tapestry5已经可以和seam继承了，不一定非要JSF |
| 返回顶楼 | |
|
发表时间：2008-07-08
qingyujingyu427 写道 看到一些回帖的人的观点都是： seam作为jboss的一个这么完美的开源项目，可惜啊，就是用了JSF这个落后丑陋违反潮流的东西。
不知道这些人有没有真正的了解够JSF， 估计是以前看论坛里各位大佬天天批判JSF，人云亦云，自己也没去了解也没有实践过就开始鄙视它了。 其实Robbin所说的seam的前4个优点都是由JSF决定的，任何JSF的实现都有这些优点。如果你想让seam不用JSF而又要保留这些优点，那只能让seam项目组自己去创造一个类似于JSF的标准而又要更先进了，看来seam项目组并不觉得这是一件简单的事情，或者他们觉得JSF很可以，总之他们没有去这么做。 个人认为，JSF非常适用于企业应用，如果你大多数的经验都是开发互联网的经验，那最好也就别来评判JSF了。 JSF多达6个的请求生命周期给开发带来很多麻烦，我开始用JSF的时候是很支持它的 特别是它的绑定机制。可是后来随着用户对交互要求的提高，用JSF真的是很受罪。有人说有facelts可以组件化开发，不知道说这句话的用没用过 这东西和JSF一样只是看起来很美化 它的继承只能有一层！完全做不到组件化开发 到后期用JSF写自定义组件更麻烦 要把ajax代码写到里面 调试起来真是恶梦。后来有一次用过Grails真的再也不想用jsf了 感觉是JSF太理想化了一点不靠近开发人员和EJB2一样。Grails这种框架才真是为了开发人员着想的 面对着Grails的易用性JSF的优点 感觉很苍白 |
| 返回顶楼 | |
|
发表时间：2008-07-08
Grails也是针对互联网应用的, Seam没有深入了解过,如果象前面朋友说的是主要针对企业开发的, 那在易用性和对页面的控制能力上肯定是不一样的,毕竟侧重不同
|
| 返回顶楼 | |
|
发表时间：2008-07-08
robbin 写道 springhill 写道 qingyujingyu427 写道 看到一些回帖的人的观点都是： seam作为jboss的一个这么完美的开源项目，可惜啊，就是用了JSF这个落后丑陋违反潮流的东西。
不知道这些人有没有真正的了解够JSF， 估计是以前看论坛里各位大佬天天批判JSF，人云亦云，自己也没去了解也没有实践过就开始鄙视它了。 其实Robbin所说的seam的前4个优点都是由JSF决定的，任何JSF的实现都有这些优点。如果你想让seam不用JSF而又要保留这些优点，那只能让seam项目组自己去创造一个类似于JSF的标准而又要更先进了，看来seam项目组并不觉得这是一件简单的事情，或者他们觉得JSF很可以，总之他们没有去这么做。 个人认为，JSF非常适用于企业应用，如果你大多数的经验都是开发互联网的经验，那最好也就别来评判JSF了。 同意这位兄弟的观点，最近参加了一次QClub的活动，发现做企业级开发的人和做互联网应用的人，在思考问题的方式和想法上真的有很大的不同。Seam作为一个面向企业应用的框架，其设计思路更多的是考虑企业应用的诸多问题，所以需要大家在了解一个东西的时候，更多的应该先了解其定位。 是的，我完全同意这种看法，企业应用架构的设计要求和互联网应用的架构设计要求完全不同。 在服务器端保存状态这是互联网应用的大忌，但是Seam这样用下来对于企业应用实现有状态的业务流程却看起来效果非常好。 企业应用的业务逻辑比互联网要复杂的多，良好的服务端状态机制对于复杂业务的开发非常有帮助，并且seam“深度集成”了相当多的企业开发的中间件比如规则引擎，工作流引擎，消息系统，远程访问，等等等。 而用来开发web的确有点烦，显得繁琐，在强调开发速度的互联网世界里显得有点重，你一个好创意出来，等你用seam隆重的搞出来，黄花菜都凉了 我现在搞得东西偏电子商务方面，业务还是有点复杂的，并且有数据整合的需要，所以暂时还是考虑用seam。如果是纯web2.0，建议还是用python, php等动态语言 |
| 返回顶楼 | |
|
发表时间：2008-07-08
xiao0556 写道 qingyujingyu427 写道 看到一些回帖的人的观点都是： seam作为jboss的一个这么完美的开源项目，可惜啊，就是用了JSF这个落后丑陋违反潮流的东西。
不知道这些人有没有真正的了解够JSF， 估计是以前看论坛里各位大佬天天批判JSF，人云亦云，自己也没去了解也没有实践过就开始鄙视它了。 其实Robbin所说的seam的前4个优点都是由JSF决定的，任何JSF的实现都有这些优点。如果你想让seam不用JSF而又要保留这些优点，那只能让seam项目组自己去创造一个类似于JSF的标准而又要更先进了，看来seam项目组并不觉得这是一件简单的事情，或者他们觉得JSF很可以，总之他们没有去这么做。 个人认为，JSF非常适用于企业应用，如果你大多数的经验都是开发互联网的经验，那最好也就别来评判JSF了。 JSF多达6个的请求生命周期给开发带来很多麻烦，我开始用JSF的时候是很支持它的 特别是它的绑定机制。可是后来随着用户对交互要求的提高，用JSF真的是很受罪。有人说有facelts可以组件化开发，不知道说这句话的用没用过 这东西和JSF一样只是看起来很美化 它的继承只能有一层！完全做不到组件化开发 到后期用JSF写自定义组件更麻烦 要把ajax代码写到里面 调试起来真是恶梦。后来有一次用过Grails真的再也不想用jsf了 感觉是JSF太理想化了一点不靠近开发人员和EJB2一样。Grails这种框架才真是为了开发人员着想的 面对着Grails的易用性JSF的优点 感觉很苍白 其实你的抨击主要来自jsf，就是那六个生命周期不能轻松的建立与ajax的直接操作关系。用ajax不方便，就开始喊叫jsf不是东西了。我的理解，企业开发，尽量杜绝ajax，就是不方便怎么了！ |
| 返回顶楼 | |
|
发表时间：2008-07-08
fangshun 写道 xiao0556 写道 qingyujingyu427 写道 看到一些回帖的人的观点都是： seam作为jboss的一个这么完美的开源项目，可惜啊，就是用了JSF这个落后丑陋违反潮流的东西。
不知道这些人有没有真正的了解够JSF， 估计是以前看论坛里各位大佬天天批判JSF，人云亦云，自己也没去了解也没有实践过就开始鄙视它了。 其实Robbin所说的seam的前4个优点都是由JSF决定的，任何JSF的实现都有这些优点。如果你想让seam不用JSF而又要保留这些优点，那只能让seam项目组自己去创造一个类似于JSF的标准而又要更先进了，看来seam项目组并不觉得这是一件简单的事情，或者他们觉得JSF很可以，总之他们没有去这么做。 个人认为，JSF非常适用于企业应用，如果你大多数的经验都是开发互联网的经验，那最好也就别来评判JSF了。 JSF多达6个的请求生命周期给开发带来很多麻烦，我开始用JSF的时候是很支持它的 特别是它的绑定机制。可是后来随着用户对交互要求的提高，用JSF真的是很受罪。有人说有facelts可以组件化开发，不知道说这句话的用没用过 这东西和JSF一样只是看起来很美化 它的继承只能有一层！完全做不到组件化开发 到后期用JSF写自定义组件更麻烦 要把ajax代码写到里面 调试起来真是恶梦。后来有一次用过Grails真的再也不想用jsf了 感觉是JSF太理想化了一点不靠近开发人员和EJB2一样。Grails这种框架才真是为了开发人员着想的 面对着Grails的易用性JSF的优点 感觉很苍白 其实你的抨击主要来自jsf，就是那六个生命周期不能轻松的建立与ajax的直接操作关系。用ajax不方便，就开始喊叫jsf不是东西了。我的理解，企业开发，尽量杜绝ajax，就是不方便怎么了！ 可惜用户和领导不会这么想。现在他们在互联网上用ajax多了去了，如果你不用，他们就会问，我选了品牌之后，后面就不能只列出这个品牌的产品吗？ 用户就是上帝呀。 不过用richfaces来做这种简单的ajax还有非常容易的，看下面的代码：
<a4j:region>
<h:inputText value="#{supplierAction.name}">
<a4j:support event="onblur" reRender="addr" actionListener="#{supplierAction.findSupplierByName}" />
</h:inputText>
<h:outputText id="addr" value="#{supplierAction.supplier.name}"/>
</a4j:region>
当焦点离开了文本输入框时，引发一次ajax动作，输入框里的值被绑定到supplierAction的name属性上后，调用supplierAction.findSupplierByName()方法，查出的结果放到supplierAction.supplier上，然后重新生成(reRender) id为addr的页面部分。 用起来是不是很方便？ 如果你要的功能,seam正好提供了，那最好，如果没有提供，那就有些麻烦了。不过seam在做企业应用方面，已能满足大部分的要求了。实际上www.seamframework.org这个外网的应用，也是用seam写的，看来如果功力足够，做一些外网应用也是可以的。 |
| 返回顶楼 | |
|
发表时间：2008-07-08
smilerain 写道 看个一点点jsf，感觉很差的一个东西，透明性，和可控性都不够好，我感说不会有很大浪花。seam 找jsf 配对，是一个错误。
现在国外JSF很火的。。。 星星浪花可以滔天～～ 哈哈 |
| 返回顶楼 | |
|
发表时间：2008-07-08
Anatorian 写道 fangshun 写道 xiao0556 写道 qingyujingyu427 写道 看到一些回帖的人的观点都是： seam作为jboss的一个这么完美的开源项目，可惜啊，就是用了JSF这个落后丑陋违反潮流的东西。
不知道这些人有没有真正的了解够JSF， 估计是以前看论坛里各位大佬天天批判JSF，人云亦云，自己也没去了解也没有实践过就开始鄙视它了。 其实Robbin所说的seam的前4个优点都是由JSF决定的，任何JSF的实现都有这些优点。如果你想让seam不用JSF而又要保留这些优点，那只能让seam项目组自己去创造一个类似于JSF的标准而又要更先进了，看来seam项目组并不觉得这是一件简单的事情，或者他们觉得JSF很可以，总之他们没有去这么做。 个人认为，JSF非常适用于企业应用，如果你大多数的经验都是开发互联网的经验，那最好也就别来评判JSF了。 JSF多达6个的请求生命周期给开发带来很多麻烦，我开始用JSF的时候是很支持它的 特别是它的绑定机制。可是后来随着用户对交互要求的提高，用JSF真的是很受罪。有人说有facelts可以组件化开发，不知道说这句话的用没用过 这东西和JSF一样只是看起来很美化 它的继承只能有一层！完全做不到组件化开发 到后期用JSF写自定义组件更麻烦 要把ajax代码写到里面 调试起来真是恶梦。后来有一次用过Grails真的再也不想用jsf了 感觉是JSF太理想化了一点不靠近开发人员和EJB2一样。Grails这种框架才真是为了开发人员着想的 面对着Grails的易用性JSF的优点 感觉很苍白 其实你的抨击主要来自jsf，就是那六个生命周期不能轻松的建立与ajax的直接操作关系。用ajax不方便，就开始喊叫jsf不是东西了。我的理解，企业开发，尽量杜绝ajax，就是不方便怎么了！ 可惜用户和领导不会这么想。现在他们在互联网上用ajax多了去了，如果你不用，他们就会问，我选了品牌之后，后面就不能只列出这个品牌的产品吗？ 用户就是上帝呀。 不过用richfaces来做这种简单的ajax还有非常容易的，看下面的代码：
<a4j:region>
<h:inputText value="#{supplierAction.name}">
<a4j:support event="onblur" reRender="addr" actionListener="#{supplierAction.findSupplierByName}" />
</h:inputText>
<h:outputText id="addr" value="#{supplierAction.supplier.name}"/>
</a4j:region>
当焦点离开了文本输入框时，引发一次ajax动作，输入框里的值被绑定到supplierAction的name属性上后，调用supplierAction.findSupplierByName()方法，查出的结果放到supplierAction.supplier上，然后重新生成(reRender) id为addr的页面部分。 用起来是不是很方便？ 如果你要的功能,seam正好提供了，那最好，如果没有提供，那就有些麻烦了。不过seam在做企业应用方面，已能满足大部分的要求了。实际上www.seamframework.org这个外网的应用，也是用seam写的，看来如果功力足够，做一些外网应用也是可以的。 俺从06年末就开始用ajax的JSF组件库,IceFace是最早的放弃的.其实一直到现在也没有一个能完全适用的，只能自己写JSF组件来扩展。ajax的JSF组件库 并不是想像中的那么好用。我想如果有一年以上JSF开发经验的应该能体会到这点 |
| 返回顶楼 | |
