【IT168技术文档】Jsf 本身是很多问题的。当然，jsf不是一项技术，而是标准。看看 javax.faces.* 包里的内容，不是抽象类就是接口，是没有实现的。 jsf 出来的时候目的也不是面向应用开发者的，而是面向组件供应商的，从这点意义上来说，jsf是成功的。Sun提供了一个reference implementation, 但是那更像是教组件供应商如何做组件的一个demo，而非真正意义上的给应用开发人员用的成型的组件。

标准因为要融合各方需求，所以内容只能是各方能力的交集。至于标准之外的东西，则需要各方去发挥。

JSF标准因为是先于成型的应用出来的（不同于EJB3的借鉴hibernate和spring，jsf299的借鉴seam），难免会有预见不足的地方。在某些地方可能作了过分的限制，而另外某些地方则完全没有规定放得太开导致标准实现商完全忽略了它们。

但是 Jsf 的初衷是不错的，而且标准本身也足够的可扩展。 所以现在才会诞生如此多的基于 jsf 的框架。 这些框架在不同程度上修复了 JSF 初始制定时的不足。

Ajax4Jsf, Facelets, Seam 是这其中三个独立的方向。

1. A4J: 用网络检测工具可以清晰地看到，每次在JSF postback 的时候，虽然可能只有部分页面需要刷新，但整个页面都会被从服务器送往浏览器。这是非常浪费的。 JSF的event-driven模型实际上非常适合部分页面刷新（试想如果没有事件模型，每晃一下鼠标显示器就把整屏幕重画，现在也就没有 windows了），但是因为ajax出来的时候JSF标准已经final了，就没有把Ajax考虑进去。对于事件模型来说，把整屏幕重画改为部分组件重画是件相对容易的事情，这也就是 Ajax4Jsf 这个项目的目的。是否开启AJAX，可以不需要javascript，只是更改页面中的某个开关（tag）就行了。

2. Facelets: JSF是建立在JSP上的，但这是完全没有必要的。JSP不是模板语言，它只是简单得把嵌入在html里的java语言原样放入Java的源文件里，实际上是混合的html和java。这种模型和JSF的事件模型没有任何互补的关系。相反，它给JSF加入了不必要的限制。Facelets的目的在于取代 jsp在jsf里的地位。它是真正的模板语言，el表达式可以嵌入在页面的任何位置，比如写成：


Hi,I'm Jordan, I think the winner of this cup is #{winner.name}, is that right?


Facelets不需要编译，页面是hot-deploy的，性能比jsp快。另外，facelets本身提供了加参模板的功能，定制新的组件可以完全不写java，只把页面里的需要提成组件的内容扔进分离的页面，并且在taglib.xml里面加入tag指向分离的页面，并指定参数名字就可以了。 JSF最为人诟病的组件缺乏的问题，在facelets这里得到了缓解，实际上是不怎么需要第三方组件就可以快速写出舒服的代码来。Facelets还有其它的功能，比如debug页面显示facelets页面出错的行号，比如无限嵌套的模板，等等。