发现JBoss Seam很棒呀！有用Seam做过项目的吗？

JSF非常适用于企业应用

Do you really know  JSF History?  Do you know SUN use JSF to Beat Struts for the  WEB APP Develope Framework? 

This is not  a Funny  Joke  "JSF非常适用企业应用".

Seam could be  a solution for Enterprise APP  JSF absolutely not the one.

Just think about  customize your own component  base on  JSF/Facelate without  Seam . Could  you still  say  JSF is   "JSF非常适用企用"?  

其实你真的看见问题的本质了。如果不用ajax， JSF用起来效率还是可以的 我指的是开发效率。运行效率就不能保证了。还有一点如果seam+JSF和Portel集成的问题 大家不知道遇到过吗？ seam的对话环境在protel里是有问题的 还有N多Bug。我抨击seam的另一点就是在于和portel的集成 也许这不应该怪seam。但是我就是用着很弄受 在用Seam的一年多时间里  打了N多补丁  都不好升级了。现在还没敢升到2。0。 还有seam的注入本身是不错的，可是在用了JSF以后 @in 会引发很多，一个Bean里注入了N多组件。你调用一个Action的时候，如果这些组件没有全部初始化 会出错。当然如果说企业应用就是有状态的 都保存在内存里了 那就无所谓了。其实这样来说 我和qingyujingyu427的观点也是吻合的

jsf的ajax组件化应用虽然被提到很高的程度来满足不同的胃口，但是我不认为这个级别的组件对于js本身还和开发者还有什么关系，开发使用的着重点仍然是在jsf组件的封装接口方面，所以，jsf即使封装了ajax它也应该叫jsf组件，而不是ajax组件，对于ajax易用问题除非在jsf前端提供一个类似facelets的js集成扩展框架来方便的与js交流，同时又能向facelets一样装饰出来一个简单级别的jsf组件，以保持组件化模式。

我感觉是你们开发方看得ajax太多了，一旦客户提出页面操作上的连续性，马上想你无刷新场景，别把它用的太多了，如果是基于jsf的js特效组件，是可以引入的，如果你们项目的大部分场景都是这种效果，那么我很难想象，客户的日常工作竟然喜欢在自己的工作平台上冲浪！

我个人认为，至少在目前，做企业应用的时候，大部分时候ajax只是改进用户体验的锦上添花的东西。这些js,并不是为了完成华而不实的特效，而是为了切实的帮助用户更轻松地使用软件。能实现这些简单实用的功能基本上就够用了，这也是我为什么认为seam在企业开发方面还是可取的原因。

说到底SEAM就是定位于做企业应用的，脱离这个目标来谈SEAM，我觉得没有什么意义。

SEAM的表现层用JSF，虽然不方便实现一些花哨的高级功能，但是做一些简单的表单足够了。SEAM的后端，则十分的强大，如果应用得当，开发效率确实能提高很多。 seam 2.0.2 bug已经很少了，有兴趣的朋友可以再试一下。

你知道java的历史么，java本来是为了家用电子嵌入式系统而开发出来的语言。结果呢，被竞争对手击败了，才转向了internet。如果我说java特别适合网络应用，你是不是该拿java被创造的历史来证明我是错的呢？
你也说SUN的本意是JSF用来击败struts等web开发框架， SUN做到了么？ 本意跟实际情况一样么？
而且JSF作为一个web开发框架， 跟"JSF非常适用企业应用"矛盾么？ 互联网应用有自己合适的web框架，企业应用有自己合适的web框架，这样有问题么？

如果你有实际经验的话，请用点实际的东西，列举几条详细的论点，来证明和推翻一些东西。不要用太虚太宽泛的表达。

当使用seam的converstaion双射策略来解决焦点对象的保存，引用问题，将是非常的舒服，并且有效治疗了httpSession在服务端对象延续机制的弊端，这个特例也反映了seam正好适合对高性能要求不是很强烈企业应用领域，这一切如果没有jsf作为对象状态机制的建设，seam只会痛苦的在无状态机制，弱对象模型的其他表现层中挣扎。

  同样g.king 的hibernate在spring的懒关系上也是很痛苦，无法把真正需要的东西延续下去，却在使用蹩脚的openSessionInView来掩盖，而ejb3的Extended persistence context经过seam的封装后的Seam-managed persistence contexts也许是唯一一个良好解决懒问题的体系了，seam集成jsf和ejb3不是作者本身的主观意思，而是框架发展的必然阶段！

I mentioned  you just try to  use   JSF to  customize your own  component , you will know  how  difficult to  use  the JSF without Seam.

，请用点实际的东西，列举几条详细的论点，

How about you write your  JSF component  or something else to  prove your point .不要用太虚太宽泛的表达. then  we can discuss  the details.  

My current  project is based on   Flex + Granite DS  + Seam . But it is out of the scope  of this    discussing.

And  I had  experience  to use  JSF to develop  WEBAPP. I also had  experience to use Seam in another  WEB APP/Eentrprise APP. 

I never say  Seam is not  good solution. But  Pure JSF is not. and  It is  proved.

I really want to  you to  give us a real example  to get  JSF for  Enterprise App then the other Framework.

Could  you do  it ? Pls be a man

  你真不能老是拿jsf和seam做对比，seam提供的一整套解决方案，jsf仅仅是给出了可实现的规范而已，seam讲究是一种策略而jsf讲究的是一种机制，为什么基于jsf而衍生出来的框架那么多，而seam只有一个！
  seam作者对于jsf的推崇是很热的，当你欣赏jsf规范的api时，就能不断感受到设计者们构思的优雅，它面向展现层提供了全方位的插接机制，基于良好对象模型的处理模式！
  例如在jsf的配置中
  SeamPhaseListener加入到phase-listener，seam就可以完全的融入jsf各个生命周期实现状态增强！
  DelegatingVariableResolver扩展了variable-resolver，spring就可以主动将控管对象集成进jsf变量解析！
  FaceletViewHandler替换了view-handler，就可以让jsf的视图部分重新由facelets进行模板化处理！
  如果你有好的富客户端渲染方式，那么就创建自定义RenderKit替换default-render-kit-id，增强渲染的效果！
  如果你想定制更高效的state机制，创建自定义StateManager替换它的state-manager！
  如果你想定制自己的导航规则程序，创建自己的NavigationHandler来替换navigation-handler
...................
这些都为扩展框架留足了余地，你完全可以使用seam并without jsf，但是jsf对于seam完全就是解耦的！ 
   

在高并发的访问时
在页面直接访问component数据时
很多时间取到的是空的,也没有任何异常
这是一个非常大的问题