【IT168 专稿】JSF（Java Server Faces）是用于 Java Web 应用程序的第一个标准化的用户界面框架。JSF 正开始凭借其 Java Web 标准的地位主导 Java Web 应用程序市场。
随着更多的开发人员使用 JSF 作为基础来架构应用程序，他们逐渐发现 JSF 的核心规范中清楚地说明： JSF 不是为成为一个完整的 Web 应用程序框架而设计的。相反，它提供一个健壮的、事件驱动的 API 和 UI 组件库，用于构建更复杂的应用程序框架。
2006年是JSF(Java Server Faces)迈向实用的第一个年头。这一年，JSF发生了几件大事：
1. 获得Framework of the Year荣誉称号；
2. Sun发布Java Studio Creator 2；
3. Exadel实现JSF对Ajax的支持；
4. Apache推出Myfaces Core 1.1.3和Tomahawk 1.1.2；
5. Sun推出JavaServer Faces 1.2。
JSF，做为JCP（Java Community Process）关于表现层的一种组件式框架，一路走来，几多欢喜几多愁，充斥着非常多的争议。现如今依然充满着关于它的各种非议之声。JSF在服务器端所存在的不足将继续成为人们所诟病的话题。
一、组件不足，导致JSF成为空军司令
众所周知，JSF被宣称为为一种组件式框架。它提供的组件有：各种输入框（hidden、text area、single field），按钮，单选框与多选框，超级链接，数据表，简单的Grid。这些组件都是标准界面用户所必需的，且数据表组件似乎是比较实用且独特的组件。
但问题在于，做为组件式框架，这些组件显得太寒碜。那么怎样的组件比较有用呢？对一个标准的Web应用程序，用户界面常用到的组件有：用户登陆、查找、查看、增加、注销。
那么在JSF中，有登陆组件么？有查询框组件么？有数据录入组件么？有数据流么？有会话状态么？在JSF中没有。当然JSF实现这些东西绝对没有什么问题。而且很多组织（软件供应商、开源组织）已经开发出了这样的组件，如Seam、IceFaces、RichFaces、Tomahawk、NetAdvantage等等。同时，一些关于JSF的书籍中也有类似的代码，如《JSF:The Complete Reference》（Schalk,Burns）、《JSF In Action》（Mann）及《Core JSF》（Geary）。甚至有些东西在web网站上都已经有了。关于JSF比较好的网站如：IBM developerWorks、http://java.sun.com、http://www.jsfcentral.com、http://www.jsftutorials.net等等。
上述大部分的参考资料与网站提供的组件都是基于JSF开发的。它们几乎都没有使用servlet过滤器（除了少数案例），同时也没有使用servlets，而是在生命周期内使用JSF组件开发。
但绝大部分的书籍资料都集中于inputText及一些相关的组件上。导航和数据输入/输出组件是很重要，但专门研究这些组件的JSF顾问也只能告诉人们这些组件同以前别的组件是如何的不一样。
JSF基于组件的设计理念是非常好的。但是JSF不应该仅仅只关注一些基础的web组件开发，它更应多关注做为标准与参考实现的双重身份。做为用户组件模型，至少应该能很好的保持用户的事件及状态，并且能简易的从模型是查找组件。但目前的JSF实现，尚缺欠此功能。 请考虑以下两种不同类型的text输入框：
<input type=”text” name=”Amigo” value=”Amigo”>
<h:inputText id=”Amigo” value=”#{backingBean.Amigo}”>
这两种方式在功能上是等效的（当然这只是表面上，但实际上，后者还有很多其它的功能）。后者使用了客户化的命名空间，较为复杂的表达式，两个新的与HTML等价的属性。
尽管两者在功能上等同的，但是人们常常习惯于使用自己所熟悉的工具（一位著名的美国将军曾说：“千万别改变一个正赢着的团队”）。已有的标准开发包一般包括：服务器端的Java、客户端的HTML及JavaScript等等。而如今，JSF将引进全新且独特的HTML标签。
而这样导致了很多的用户对JSF浅尝辄止。对于已经熟悉<input/>的用户来说，为什么又要使用<h:inputText/>这样的标签呢？人们找不到必须使用此种标签的明显理由。尽管<h:inputText/>功能很强大，而具有Ajax功能的其它组件更是如此，JSF的导航功能很不错，它的表达式语言将成为一种标准。
但真正的问题在于，用户不得不使用如此基础的组件去构造已存在的标准组件。于是使用JSF特色的基础组件创建标准组件在开发难度上将是一个很大的跳跃。虽然在理论是可以实现，但是往往让用户无法忍受。
细心的读者会发现上面的用词：已存在的标准组件。这是有意如此叫法。如前所述，有许多的组件框架可以提供许多有趣有用且惊人的各种标准组件，以及一些必不可少的扩展组件，如日期和时间选取组件、多行文本框及界面调整器等。而在此方面将JSF推向正确方向的公司当首推：Oracle。
Oralce提供的ADF（Application Development Framework），是Oracle为 JSF 开发的一个大型组件库，是一系列的具有某一功能的部件集。做为一个end-to-end的框架，和Spring一样它在企业应用架构的每一个层次都提供了它的支持，表现层框架也提供了对JSF标准的参考实现。需要wiki吗?ADF Faces提供了wiki JSF组件。需要一个论坛？ADF Faces提供论坛JSF 组件。
想象在服务器端为每一个内容版块创建一个JSF组件，并将这些组件添加在一个面板（panel）上。在每一个内容版块，为每一个主题添加ADF论坛组件及wiki组件。当然，没有JSF这也是可能实现的。但是JSF组件不用客户编写全部代码而能实现此功能的能力，是很吸引人的。在JSF的推广上，出现了令人痛心的失误。如果JSF以JSP3.0的名义推出，那么JSF的日子恐怕要比现在好过得多。其实问题并不在于JSF本身，至少大部分不是。真正的症结在于JSF的理念，以及对JSF的展现与宣传方式。
就JSF这项技术而言，Sun的商业策略实在是值得商榷。在JSP已经深入人心的时候，为什么不继续沿用Java Server Pages的这个如雷贯耳的名称，而要标新立异地推出一个Java Server Faces的怪物呢？而再看Microsoft，在ASP流行开来之后，继而推出ASP.NET，是多么的顺理成章。
如果JSF没有叫做JSF，而是叫做JSP 3.0，情形会是如何呢？可以预见，大批的JSP爱好者会蜂拥而至，庆贺JSP的新版本；而一批“牛人”们很快发现，JSP的新版本，引入了他们期待已久的组件模型和事件驱动模式，JSP终于有了和ASP.NET抗衡的资本；于是，“牛人”们必定奋笔疾书，以超凡的热情四处撒播JSP 3.0的种子。
不管怎样，当JSP如日中天时，不知借JSP之势点燃JSF的大火，反而另起炉灶，Sun是否也在痛定思痛呢？也许Sun主观上并不存在这样的故意性，但客观上造成了这样一种局面，也是不可原谅的失误。
有了合适的组件集，问题将不会再是JSF本身了。而是JSF使用的“生态环境”。良好的“生态环境”的建立也是件较容易的事情。当使用的用户足够多时，良好的“生态环境”就开始建立了。
对于JSF而言，这样的“生态环境”已经部分的建立了。除了组件供应商外，还有很多开发JSF的工具。如：JbossTools（或称Exadel Studio更适合）、BEA Workshop（Workshop与NitroX的M7产品的合并产物）、Oracle的Jdeveloper、MyEclipse、NetBeans、IBM的JSF工具及IDEA对JSF的支持。
关于JSF的开发工具大概就这些了。也许有人会说，开发JSF很大程度上依赖于这些开发工具。其实这样的说法并不公平。对初学者而言，这些IDE工具将帮助他们更容易学习JSF。
许多的开发者常对初学Java人员建议，最理想的Java IDE是记事本（notepad）及命令行（cmd），那么有些人就由此推论，JSF最好的IDE应该也是记事本等简单的编辑器，而JSF专业的开发工具将让初学者“偷懒”，从而让他们对JSF的理解浮于表面。这常常使JSF初学者迷茫。
那是不是意味着要放弃使用JSF的IDE工具吗？当然不。因为我们不能由于工具能提供更加容易的开发过程而认为工具是有缺陷或框架是有缺陷的。
JSF的IDE并不能吸收大量的JSF用户，这也就说明了JSF的“生态环境”在引导JSF初学者方面发挥不够。“生态环境”代表着JSF的能力及威力。然而，它并不能向初学者展现它的核心思想，亦没有解释清楚初学者首先需了解的内容，同时没让初学者明白JSF框架所能提供而其它框架却不能提供的优点。
真正的问题是在于，JSF基于如此基础的组件，并不能直接为用户提供更有利的组件，除非用户自己再次开发基于JSF更好的组件。而用户在没有发现JSF的潜力之前，是难以开发更好的组件集的，同时，相关的文档于此也可能将无济于事。
四、 结论
组件开发者可以停止重复开发的车轮了。每个人都有一个tab面板、菜单组件、spinner、拖放机制。这些已经成熟了。对于更新更好的实现方式是欢迎的，但对“我也能”的实现方式，其实并不利于技术的传播。JSF所需要的，正是一个基于界面模型而开发的组件集，它将是界面的标准实现。关于此组件集的文档，当然也得简单明了，易于初学者学习与掌握。
JSF发展速度很快。前面所提及的书籍都是关于JSF的优秀资源。特别是Seam项目的书籍，更是关于JSF的快速入门书籍。JSF的优势在于它是一种标准，但仅仅是标准是不够的。因为并不能做人们所期望的事的标准，总有一天会被其它的标准所代替的。就笔者而言，JSF还并不胜任此标准，当然每位开发人员都会做出自己最终的决策。
不管怎么说，JSF总归是一种非常有潜力的组件框架。当然它也不是唯一的组件框架，本文的主题并非比较各种组件式框架。但好说歹说，JSF是J2EE的一部分，组件还在不断扩展和完善中，既然它是J2EE 5.0的实现标准，其潜力还是巨大的，它将像JSP一样，你可以只是比较淡漠的关心它，但JSF还是会向着它的方向进发，不管你喜欢与否。
JSF同其它的框架一样，是平等的。它成一种标准，意味着用户与实现者都有一个共同遵循的平台。如果JSF遵循共同的规范，则你可以想象JSF的运行机制。如果不是，则可以不用考虑它了。
JSF存在的问题是可以解决的，也正在被解决。已经出现了一些组件集，Facelets取代JSP，使得Web页面的模板化更加容易，将带来更快更简洁的性能。JSF2.0专家团的成立，将会把Java EE的简单模型带给JSF。同时，相关的文档将会更新与修订，同时将会有新书出版（不仅仅只是关注Jboss使用JSF开发的Seam项目）。
当笔者在抱怨JSF的同时，作为开发人员，也在努力寻找解决问题的办法。如下是笔者的一些初步看法：
1. 使用facelets来代替JSP。
2. 尽量使用ADF或Seam，而少用或不用RI或myfaces。
3. 结合Spring来增强JSF的扩展性。
4. 别再抱怨JSF，毕竟它只是一个标准规范，而不是一种具体的实现框架。
