一般的网络程序和服务器的交互是完全自由的，用户在浏览器上对页面操作可能会引发对任一URL的任何一种方法的请求，点一个普通的超链接，引发一个GET 操作，单击一个提交按钮，引发一个POST等等，这都是完全自由的。但是在JSF的世界里，浏览器与服务器之间有着一个固定模式的交互方式，这是JSF的 节奏。
让我们看看这个节奏：a.浏览用GET请求一个页面 -> b.JSF生成指定页面的组件树，产生html页面返回 -> c.用户对浏览器上页面控件操作，引发一次对当前页面的POST请求 -> d.JSF重建组件树，执行业务动作，返回一个 重定向 。 然后就是一直循环下去，简要的来看就是 get -> 200 OK -> post -> 302 redirect -> get -> 200 OK -> post -> 302 redirect …。如果导航规则里没有指定POST后到其它页面，后面就不会有redirect，会把POST后的组件树再重新渲染成HTML返回。JSF的组件树 在浏览器的GET请求时被创建，在POST请求时被重建。你配置的导航规则决定了redirect到哪个页面，即浏览器下一次会对哪个页面发GET请求。 你获得的页面里面由h:commandButton h:commandLink等生成的链接按钮等在被触发时，都会引发一个POST请求。你在处理POST请求时放在request里的对象，在经过 redirect到为了GET生成页面时，已经不存在了。在没有SEAM的conversation的时候，我们只好把要夸越多个请求，又不需要存活于整 个SESSION的对象放到SESSION里，让SESSION变得杂乱充满隐患。
为什么JSF要让h:commandButton和h:commandLink都用POST方式来提交数据呢？JSF为了能够在用户点击链接或按钮后能重 建组件树，必然要在返回给客户端的HTML里添加很多额外的参数，这些参数是JSF自动生成的。如果用GET方式，这些信息都将写在URL里可能会超长， 出问题，所以最好的方式就是用POST了。另外，JSF也依赖于GET POST方法来确定你是要新建一个组件树来查看页面，还是要重建一个组件树来执行业务动作。这种方式等于重写了HTTP GET POST的语义，与REST的理念正好相反。如些的限定，也让你写页面不能放开手脚。
最后说一点，我非常不喜欢这种方式。

• 前一篇: JSF vs MVC
• 后一篇: 优化jboss以提高性能