seam前端提速
Seam使用了richfaces做为jsf的组件库。richfaces的功能确实不错，但是性能上存在一些问题。一些简单的页面，用firefox打 开，YSlow插件都显示花掉了数秒时间。通过 firebug和YSlow插件，可以看到，打开页面的时候，浏览器会向发起很多请求，以下载javascript和css，而且这些文件的体积还不是很 少。减少请求次数，减小传输数据量，可以一定程序上改善客户端体验的性能。查阅richfaces的文档，终于找到了解决方法。
原来richfaces的默认方式是按需添下载js和css，更改它的一些参数，可以让它变成全部下载。方法是在web.xml里添加以下内容：
<context-param>
<param-name>org.ajax4jsf.COMPRESS_SCRIPT</param-name>
<param-value>false</param-value>
</context-param>
<context-param>
<param-name>org.richfaces.LoadScriptStrategy</param-name>
<param-value>ALL</param-value>
</context-param>
<context-param>
<param-name>org.richfaces.LoadStyleStrategy</param-name>
<param-value>ALL</param-value>
</context-param>org.richfaces.LoadScriptStrategy参数让richfaces生成的页面里引用到所有js和css，并且是合并压缩过的版 本。因已经是压缩过的了，不需要再让ajax4jsf再压缩了，所以把org.ajax4jsf.COMPRESS_SCRIPT设成false。这样设 置过后，打开页面时发现，测览器这回只会下载两个js和一个css了，速度确有所提升。
另外，richfaces的rich:calendar组件不知道为什么，每次生成都会花掉很多时间。在我的开发机上，一个页面里如果添加一个rich: calendar，就会使页面生成时间多加一秒。看来richfaces还有很多要改进的地方。JSF的post->redirect-> get的方式(参看这篇文章)也是使用户体验慢的一个原因，但是这个JSF的一个基本的设计，难以改变。我很讨厌这种方式。再在回头看来，seam是不错，但是 seam把自己绑定在jsf上真是一大失误！
一般的网络程序和服务器的交互是完全自由的，用户在浏览器上对页面操作可能会引发对任一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的理念正好相反。如些的限定，也让你写页面不能放开手脚。
最后说一点，我非常不喜欢这种方式。
原来richfaces的默认方式是按需添下载js和css，更改它的一些参数，可以让它变成全部下载。方法是在web.xml里添加以下内容：
<context-param>
<param-name>org.ajax4jsf.COMPRESS_SCRIPT</param-name>
<param-value>false</param-value>
</context-param>
<context-param>
<param-name>org.richfaces.LoadScriptStrategy</param-name>
<param-value>ALL</param-value>
</context-param>
<context-param>
<param-name>org.richfaces.LoadStyleStrategy</param-name>
<param-value>ALL</param-value>
</context-param>org.richfaces.LoadScriptStrategy参数让richfaces生成的页面里引用到所有js和css，并且是合并压缩过的版 本。因已经是压缩过的了，不需要再让ajax4jsf再压缩了，所以把org.ajax4jsf.COMPRESS_SCRIPT设成false。这样设 置过后，打开页面时发现，测览器这回只会下载两个js和一个css了，速度确有所提升。
另外，richfaces的rich:calendar组件不知道为什么，每次生成都会花掉很多时间。在我的开发机上，一个页面里如果添加一个rich: calendar，就会使页面生成时间多加一秒。看来richfaces还有很多要改进的地方。JSF的post->redirect-> get的方式(参看这篇文章)也是使用户体验慢的一个原因，但是这个JSF的一个基本的设计，难以改变。我很讨厌这种方式。再在回头看来，seam是不错，但是 seam把自己绑定在jsf上真是一大失误！
一般的网络程序和服务器的交互是完全自由的，用户在浏览器上对页面操作可能会引发对任一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的理念正好相反。如些的限定，也让你写页面不能放开手脚。
最后说一点，我非常不喜欢这种方式。