Faces Client Components

JavaServer Faces（JSF）是一种 Java EE 1.4 组件，最初是作为 JSR 127 开发的。这种技术的关键目标是，降低为 Java EE 应用程序开发用户界面时要求 Java 开发人员具备的技能水平。因为 JSF 是一个框架，它提供了许多开箱即用的功能；在过去，开发人员在用 JavaServer Pages（JSP）构建同样的用户界面时需要手工编写这些功能。

例如，假设您有一个大型 JDBC™ 结果集，需要将它向用户显示。JSF 框架提供了一个 DataTable 部件，可以用来显示数据。如果使用简单的 JSP 构建用户界面，您就必须管理用户与这个数据表的交互，并决定应该向用户显示哪些数据行。

通过使用 JSF DataTable，当用户点击 Next 来显示表中的后 x 行数据时，JSF 框架将会处理 Next 请求，您不必自己编写任何代码。尽管 JSF 简化了创建丰富的 HTML 用户界面的过程，但是根据设计 JSF 是一种基于服务器的技术。对后 x 行数据的请求从浏览器发送到服务器，JSF 框架代码在服务器上处理这个请求。JSF 需要一次到服务器的请求/响应往返。

为了改进基本的 JSF 部件，IBM 的 Rational® Application Developer V6 引入了 Faces Client Components。Faces Client Components 是 JavaServer Faces 技术的一种扩展，允许在客户端执行某些 JSF 框架服务。例如，如果在上面的示例中使用 DataGrid Faces Client 组件，那么后 x 行数据的显示就不需要到服务器的请求/响应往返。

对于 Rational Application Developer JSF 开发人员，使用 Faces Client Components 是自然的选择。为了使用 Faces Client Components，要创建一个 Faces JSP 页面并选择 “Basic with client-side data caching ” 作为模型。当在 Rational Application Developer 中构造用户界面时，只需从 Rational Application Developer 的工具面板中的 Faces Client Components 部分中选择适当的 UI 控件。

在 Faces Client Component 的幕后发生了许多情况。会将 JSF 控件的 JavaScript 实现下载到浏览器中，并使用符合行业标准的 Service Data Objects 在浏览器和服务器之间进行通信。但是，这一切理所当然都是对用户隐藏的；用户只会注意到，与典型的基于浏览器的应用程序相比，他的应用程序的响应速度快多了。

Ajax

Ajax（异步 JavaScript 和 XML）是 Jesse James Garrett 创造的一个术语，它是指一种基于标准的技术/设计模式，用来为服务器部署的应用程序开发比浏览器更好的用户体验。Ajax 对服务器技术没有什么要求，可以处理 Java EE 应用程序、.Net 应用程序和其他应用程序。通过使用 Ajax，可以编写 JavaScript 代码来改进 HTML，创建出丰富的交互性用户体验。例如，JavaScript 可以执行本地用户输入验证，为相同的数据提供不同的视图（条形图、表格、饼图等等），或者通过浏览器的 XMLHTTPRequest 对象与应用程序的服务器组件进行异步的交互。

根据 Gartner Group 的 Hype Cycle for Emerging Technologies 2000 报告（2006 年 7 月 18 日），Ajax 已经达到了 “过度期望的顶峰”，“幻想” 已经开始成为现实了。看看书店里有那么多 Ajax 图书，就能够知道这股风潮有多么热了。按照我的观点，有三种东西帮助 Ajax 跨越了 Geoffrey Moore 指出的技术鸿沟：

现代浏览器。 在过去，编写 JavaScript 的开发人员必须处理 Netscape、Internet Explorer 和其他浏览器之间的许多不兼容问题。在某些情况下，甚至同一种浏览器的不同版本也有不兼容问题。尽管仍然存在一些不兼容问题，但是大多数内部网应用程序通常需要 Internet Explorer 5.5 或更高版本和/或者 Firefox 1.0 或更高版本，在这些浏览器中以前存在的大多数不兼容问题已经被纠正了。近来组成了一个开放的行业协会 OpenAjax，它的目的是解决 Ajax 的不兼容性问题，以及解决其他 Ajax 相关问题。

Ajax 工具包。 在过去，希望使用 Ajax 的大多数开发人员实际上必须从头开始，而 Ajax 工具包现在可以替他们完成许多繁重的工作。工具包提供了各种预制的基于 JavaScript 的用户界面控件（部件），让开发人员可以轻松地创建基于 Ajax 的用户体验。工具包通常还提供更高级的抽象，从而对开发人员隐藏前面提到的浏览器不兼容问题。

工具。 直到最近，大多数 JavaScript 开发人员实际上没有开发工具来帮助简化开发和调试。从 Firefox 浏览器发布开始，它就为 Ajax 开发人员提供了一些有用的插件，而且 IBM 最近在 Ajax Toolkit Framework 中集成了一系列有用的技术来帮助进行 Ajax 开发。ATF（Ajax Toolkit Framework）可以从 Apache 站点免费下载，它提供一个基于 Eclipse 的 Ajax 开发环境。ATF 提供的工具包括 JavaScript 语法敏感的编辑器、JavaScript 控制台和 XMLHTTPRequest 对象查看器。ATF 还附带三个预制的个性化组件：Dojo、Zimbra 和 Rico。

最后，按照我的观点，当 Google 发布基于 Ajax 的 Google Maps 应用程序的 beta 版本时，Ajax 真正的转折点到了。以前使用过地图 Web 站点的任何人都会很快看出 Google 地图软件的优点。非技术人员感到吃惊，想知道 Google 是怎么做到的；而知道其原理的程序员开始注意到 Ajax，并开始考虑如何使用基于 Ajax 的技术改进自己应用程序的易用性和响应性。

纯 HTML

尽管许多开发人员认为所有用户像他们自己一样，使用最新的 Firefox 浏览器并带 10 个最流行的插件，但事实是许多机器仍然使用 Netscape 3.x 或 Internet Explorer 4.x 来访问互联网。使用这种水平的浏览器可能是为了使用某一应用程序（它的源代码已经丢失了，无法修改了），或者是因为用户非常保守，他们按照 “如果没有出问题，就不必自找麻烦” 的原则来对待浏览器升级，所以仍然使用 Internet Explorer 4.0。

尽管 HTML 显然不能提供其他技术可以提供的那么丰富的用户体验，但是基于 HTML 的用户界面仍然会长期占据一定的地位。还没有其他技术能够像纯 HTML 用户界面一样让那么多用户都能够使用。因此，在未来的许多年内，许多应用程序仍然会提供这种用户界面。

结束语

总的来说，当今业界的重要方向是改进服务器提交的应用程序的用户体验。Ajax 仍然还不太成熟，但是已经有了一定的实力，而且许多企业（包括小型和大型企业）已经开始在生产中使用它。本文提到的其他技术没有得到这么大的关注，但是到目前为止还不能明确地说它们没有前途。

还存在其他用户界面技术，包括商业产品和开放源码产品（比如 Nexaweb、Backbase 和 JackBE），但是由于篇幅限制本文没有提到它们。关键一点是，这些技术都不是放之四海皆准的，所以没有任何技术对于所有场景都是最佳选择。这些技术都有各自的优点，都有其适合的场景。

那么，如何做出选择呢？对于初学者来说，如果技术选择背后的主要目标是接触尽可能多的用户，那么没有任何技术能够超越老式的 HTML。在另一个极端，如果您需要无连接操作，而且可以在用户机器上安装应用程序的组件，那么基于 EclipseRPC 的替代品之一（Workplace Managed Client 或者 Lotus Expeditor）是最佳选择。

如果需要的丰富用户体验只能通过 Flash Player 来获得，那么可能应该使用 Flex 或 OpenLaszlo。如果使用 JavaServer Faces 构建应用程序，那么使用一些 Faces Client Components 会更好。

最后，如果您的目标只是在现有的 HTML 用户界面中增加一些易用性特性，或者是提供基于标准的插件免费的丰富用户体验，那么应该考虑使用 Ajax。按照目前的舆论，Ajax 似乎成了最流行的 Web 2.0 技术选择，但是我不能肯定其他技术在成熟之后会不会取代它的地位。

选择正确技术的关键是，让应用程序的需求决定对用户体验技术的选择。尽管这个建议似乎是理所当然的，但是在许多情况下开发人员所做的正好相反，他们被时髦的技术宣传所蛊惑，做出 “技术驱动的选择”，这常常导致许多困难的实现和部署问题，从而在开发项目时导致严重的延误和问题。不要让这种情况发生在您身上。