我目前的项目前端使用的是jsf+seam的架构，目前项目已经进入尾声，我想把一些心得体会给大家说说，以便大家在使用jsf的时候，少走弯路。
1.异常处理问题：请为jsf加入seam框架，看看Seam - 无缝集成JSF，共三部分，里面告诉了你怎么在servlet容器下配合spring使用seam，seam不是一定要在ejb3和jboss下才可以使用。因为单独使用jsf的话她的异常处理功能很简陋，跟踪不到你想看的地方，对于开发很不方便，你只有打开日志才能看到问题所在，而seam在加入phase-listener以后，对jsf不同的生命周期都进行了功能增强，即使不使用seam任何的功能，她也能毫无保留的输出所有的异常栈。
2.css问题：如果你想在你的项目中使用jsf，css太重要了，很多刚开始使用jsf的人都不是很习惯jsf基于块结构开发页面，因为jsf让你注意的是展现的内容，而不是展现的样式，这是完全符合w3开发html的初衷，大家使用<table><tr><td>来做页面展现布局，其实是错误已久的方法，如果在jsf中能了解如何使用css进行布局，jsf不适合复杂页面设计这句话就不攻自破了。
3.细心的使用dataTable组件，数据列表是最常用的页面组件，但是我毫不留情的说jsf的dataTable组件的实现简直太滥了，它就是jsf开发一大祸根。没有很方便的解决特定行样式显示的问题，没有解决回退按钮风险问题，没有dataScroll和dataTable组件进行数据库分页的优雅办法，数据提交的幻影问题，我的开发很多时间用在了dataTable的和其他组件块融合上面。不过jsf1.2通过统一el，加入了对jstl的foreach标记的支持，我虽然还没有使用，但是我认为这有可能成为数据列表开发的一个有力补充。
4.建议把jsf的模型bean和后台的业务bean合二为一，这样可以在前端提交页面与模型绑定的同时，完成业务bean的数据封装，并且交由服务层处理一气呵成。这样做有个好处，就是我们会想方设法通过各种手段在第一时间就完成模型bean对业务bean的封装，消除服务层对dto的依赖。这样是可行的，因为jsf的页面绑定机制提供了很好的帮助。
5.请考虑多的使用convert组件，比如列表页面有个radio块，提交radio值就是一个int数值，然后在展现逻辑去恢复这个radio值对应的业务模型，这样增加了展现逻辑处理页面数据的负担，而且不好管理，如果把这个工作放在自定义的convert中，让convert在页面上显示int数值，在提交上寻找对象，那么页面和服务层就屏蔽了这样的工作，看到的都是对象的进出。
6.我使用了myfaces一个自己的组件<t:updateListener>,就是跨页面专递参数，非常好用，刚使用jsf的朋友，可以看到跳转的下一个页面用它怎么做，但是建议传递模型对象，不要传递数值，你使用jsf就是因为她是基于对象考虑页面设计的。
7.小心使用session来处理jsf，jsf过多的使用了session，但是我可以肯定一点，展现层一定是需要基于状态的方式来做的，这样可以简化开发，无状态的方式会带来更多的无序代码。不是每个人都是高手。可以考虑使用seam的conversation来处理，她的长会话特别适合业务编辑，默认的短会话会填补jsf有时容易丢失的短期数据。
8.调试jsf的问题：有时你使用jsf想知道你的数据在哪个阶段变化了，你不会把jsf代码加入到自己的工程中来调试把，请加入自定义的phaseListener，继承phaseListener这个接口，你可以在把你的程序设置在任何阶段跳出来进行调试。
9.分页的问题：在google搜一下，有个http://www.blogjava.net/steady/archive/2005/12/30/26013.aspx提供了分页的方式，我就在使用,这是目前最可能的方式了把，呵呵，不过要注意她使dataTable的values直接使用了dataModel，她与seam的@dataModel是不兼容的，所以不能使用seam的@dataModel功能，需要使用get方式了。
10.如果想使用ajax4jsf等ajax框架，你需要使用facelet，让页面成为标准的xhtml，记好了，不要写了一大堆才发现这个问题。
11.如果你在dataTable列表页面使用了radio的话，你还想在列表上做一些link操作，一定要在操作上加入immediate=true，否则在没有选择radio的情况下她是不会让你过去的。并且列表中要使用selectOneRadio,如果使用checkbox就要使用selectBooleanCheckbox.组件。
12.对于doGet的方式请使用seam的<s:link>组件，<%=request.getContextPath() %>问题，提交引起的书签问题都迎刃而解。
13.如果你导入了其他页面，而没有使用facelet的话，那么导入的那个页面就要完全符合jsf组件的渲染方式，混合html会解析不出来。反过来在主页面应该尽量多使用jsf标记与html混合的方式，这样可以使开发变得简单，尽管有时候jsf会很丢丑，你试试每个html组件都有个render属性就知道了。jsf1.2已经把混合的html作为一个output组件来输出，可以和jsf组件兼容，是件好事。对于混合html这种方式，我想说你关注的是jsf组件和模型的关系，而不一定页面都得是jsf组件标记。
14.不要相信jsf运行的速度慢，jsf虽然在树形组件处理上，每一个阶段都经历了递归遍历，但是要相信jsf依然很快，我现在的系统很快，如果你使用后很慢那是项目产生了问题，而不是框架的产生了问题。
15.相信jsf一定是下一代表现层的王者，这很重要。
就这么多把，jsf的能多经验，我还在摸索当中，有机会还会和大家交流
fangshun1980@hotmail.com
引用:
http://www.blogjava.net/fangshun/archive/2007/10/20/154469.html
前一段时间我写过一篇共享我在项目中使用jsf的一些经验，主要是概要的提出了一些jsf使用上的建议，这次我想在文章里主要是把seam在jsf中的使用经验提一下，能让更多的人了解seam的实际应用和优势。
1.seam配置时要注意的地方：
（1）faces-config.xml里面要加入一个seam的阶段监听：
<lifecycle>
<phase-listener>org.jboss.seam.jsf.SeamPhaseListener</phase-listener>
<!-- <phase-listener>com.future.egov.jsf.ext.event.DebugPhaseListener</phase-listener> -->
</lifecycle>
seam动起来的条件就是从这里发起的，seam通过这个监听器对jsf的各个阶段进行必要的增强以及植入自己的CONVERSATION生命周期，对于这个监听器的具体细节工作，我还需要更多时间研究,仍在了解中!
(2) 一定要在工程类路径的根下放置一个seam.properties文件，你可以设置为空内容，主要是引导seam在初始化的时候加载这个路径下所有标注为seam组件的对象（通过@Name注释），http://www.ibm.com/developerworks/cn/java/j-seam1/ seam无缝集成jsf给我了提示！
(3)web.xml下最小配置是加入seam监听器
<listener>
<listener-class>org.jboss.seam.servlet.SeamListener</listener-class>
</listener>
在容器加载工程的时候，初始化seam框架。
以上三处的配置，你就可以在任何容器中使用seam了！更多的配置大家可以找参考了解吧，我目前在项目中就使用了以上配置。其他配置主要是在seam对ajax，ejb3的支持上，不过seam很新，什么事都会发生！
2.常用的注释：（所有被seam定义的领域对象都可以认为是seam组件）
（1）@Name(XXX)，需要在你的领域类上定义，定义了seam组件的名称，对于jsf来说就是backing-bean，也就是说你不用在faces-config中配置managedbean了！
（2）@Scope(ScopeType.XXX)，可以在你的领域类上定义，表示这个被定义的seam组件在什么上下文中，jsf中主要包括page,event,session,application,conversation这些Scope。我在项目中主要使用event,session,conversation。event就是把组件放入了request中，session同理，conversation是seam独创的声命周期，conversation短声命周期类似request，但是会保存一些jsf容易在请求中丢失的数据（jsf只是保存组件，不保存组件渲染的数据，除非是EditableValueHolder组件，有时候需要通过myfaces的save组件和updateActionListener组件来恢复这些数据），具体保存细节，需要看使用的情况，我有这样一个经验：当定义成event上下文，在页面的一次请求中，有些数据请求时还在，但是到渲染时就不见了，常见在dataTable组件，myfaces的commandNavigation组件，但是换成conversation上下文，这些数据在渲染时又找回来了。但是对于跨度比较大层面，我还是推荐使用myfaces提供的保持机制，我一般使用updateActionListener，而save组件在seam1.2.1的环境下会出错。如果再有更大跨度，就可以使用conversation上下文的长会话了。
（3）@Begin（join=true）,@End(beforeRedirect=true)，当触发了带有@Begin标记的方法，conversation的长会话就这样开始了，主要是为了长时间使用已经加载到conversation域中的对象或者属性（如果定义了conversation但并没有加载的可不算）：join=true就是告诉你会话中有同名值时继续赋值，还有一个注释参数ifOutcome=XXX，就是看你的方法返回的字符串是否和ifOutcome定义的字符串相匹配，如果匹配就开始长会话。当在长会话期间执行到某个方法带有@End标记那么这个长会话就会结束，这样防止了内存泄漏问题，我认为这是一个权衡的结果，也许用户真的会点击那个带有结束标记方法的按钮。beforeRedirect为真就会在结束时清掉conversation上下文所有的信息，如果beforeRedirect=false，conversation只是变成短会话，在结束后的那次请求中还可以使用conversation中的数据，一般会用在messages提示这个应用场景中使用，但是如果要返回数据列表有时就需要清空所有数据，防止数据列表还会重现长会话开始前的情况。
（4）In(value=XXX,rquest=false,ScopeType=XXX)，Out(value=XXX,rquest=false,ScopeType=XXX) seam把它定义为双射。In是最常用的标注，你可以使用In导入一个jsf的EL变量来获取jsf模型，例如我要获取spring的业务bean，而且业务bean已经定义成backing bean，利用spring与jsf集成的方法：
<!-- Managed Beans for options.jsp -->
<application>
<variable-resolver>
org.springframework.web.jsf.DelegatingVariableResolver
</variable-resolver>
<locale-config>
<default-locale>gbk</default-locale>
</locale-config>
<message-bundle>resources/MessageBundle</message-bundle>
<!-- <view-handler>com.icesoft.faces.facelets.D2DFaceletViewHandler
</view-handler> -->
</application>
在seam组件中这样声明：
@In(value="#{userService}", request=false)
private UserService userService;
这个示例为seam组件注入了由spring管理的用户服务对象，它的value是从jsf EL变量中获取，request=false在告诉seam，如果当前的值没有找到，那么设置为空，否者当出现没有找到的情况，seam会抛出空异常。
@Out属性主要是把处理过的属性值会由seam重新再付给上下文也就是Out中所定义的ScopeType上下文，我认为虽然是seam的一个特点，但是在我的应用中不多，主要是注入而非双射！如果它真的能在短期Conversation中有所作用来代替Myfaces的数据保持机制，我想会好些，我目前只是在长Conversation有所应用。
[email=3.@Factory]3[/email] [email=.@Factory].@Factory[/email]，@DataModelSelection，@DataModel，它们主要来代替数据列表的使用，主要是减少了代码量，Factory是在请求值阶段就对需要实例化的对象进行创建，DataModelSelection定义的属性，可以透明的抓取数据列表选择的单行数据，DataModel属性减少了不必要的get，set。然而我在实际的使用中由于很多不定的情况，大部分的使用上又回到jsf标准的get方式。 这种开发方式我认为seam的目的是想屏蔽与页面不必要的关系细节，让开发只需要重视真正的业务，是一个标准的面向对象式结构，当jsf的体系结构的不断优化，类似这种开发方式我想会越来越有用。
[email=4.@RequestParameter]4. @RequestParameter[/email]是个很有用的注释，它自动把当前属性和页面同名的request提交值绑定在一起，虽然这样使用违背了jsf所追求的面向对象化，http透明化，但是实际开发中会后很多意想不到的情况，有时候在集成式页面这样的做法会很有用，当你的页面中不仅仅有jsf标签就清楚了！
seam的其他方面问题我会抽空整理一下，seam目前也是在不断更新当中，明年出台的webBeans规范的前身就是seam，其实我更关注的是seam在整个j2ee体系中的角色，它到底是想替代struts的application？还是想替代spring的manager?也许有更多的想法！