使用 Struts Validator(1)

开始之前

关于本教程

本教程将指导您安装和配置 Struts Validator 组件。我将介绍如何使用 Validator —— 至少在一个简单的级别上使用 —— 并确保它能在具体的 Struts 配置中工作。而且，如果以前没有用过 Struts（但是却有足够的勇气跟随本教程），那么可以回顾 附录，里面提供了 Struts 安装的速成课程。

完成本教程后，就设置并运行了 Validator，应当能够自如地把 Validator 配置成在自己的 ActionForm 中使用。另外，还会看到一些非常简单的 Validator 应用，就 Struts/Validator 应用程序编程提供了一些前瞻性的体会。

谁应当阅读本教程?

本教程是为那些对 Java 技术、Tomcat servlet 引擎和 Struts 应用程序框架有一定熟悉程度的 Web 开发人员编写的。

如果目前使用的 servlet 引擎不是 Tomcat，那么需要熟悉所使用的 servlet 引擎的设置和配置。本教程假设使用的是 Tomcat，所以没有提供针对非 Tomcat 配置的额外细节。请检查 Struts 的文档，了解在 Tomcat 之外的 servlet 容器中安装 Struts 的更多信息（在 参考资料 中有一个链接，链接到文档中的特定小节。）

本教程只处理 Struts 的配置，所以还需要对 XML 文档有最起码的熟悉。对于设置 Struts 的机器，还应当拥有管理访问权；我们将添加一些 JAR 文件并修改 Struts 的核心设置，让 Validator 启动并运行。还需要了解一点声明性编程（如果是新接触声明性编程，还是请参阅 参考资料）。

前提条件

要跟上本教程，需要一台安装了 servlet 引擎（例如 Apache Tomcat）的机器或 ISP。我强烈建议在本地的开发计算机上或者在非生产的 ISP 帐户上运行本教程。换句话说，不要在为成千上万用户服务的机器上试验，因为将要对 servlet 容器做修改，可能不得不多次重新启动容器服务器。

我使用的是 Mac OS X 上的 Java 平台 5.0 版，但对本教程来说这两样并不是必需的。在本教程中看到的一些捕获的警告和输出体现了这一点。另外，我使用的是 Tomcat 5.5.9，它要求 Java 平台 5.0 版（要让它在早期的 JVM 中工作需要下载特殊代码才能做到）。虽然我强烈建议采用最新的 5.0 版本，但本教程并不要求 Java 平台和 Tomcat 的特殊版本。

还需要一个文本编辑器（如果愿意，也可以是 XML 和 Java 编辑器），最好是用一个可以同时打开多个窗口的编辑器。有许多文件需要配置，所以在终端窗口中用 vi 可能有点过时。（比如，我用的就是 Mac OS X 上的TextEdit，所以您也不需要什么太奇怪的东西。）

最后，请确保下载了 Struts 引擎和示例应用程序（请参阅 附录）。我用示例应用程序来避免过多地陷入设置 Struts 表单的细节，因为这并不是本教程的重点。

Validator 本身要运行的话还需要几个库，但是我们将在 安装 Validator 框架中讨论这些库。

构建带有验证的“防弹” 应用程序

验证的重要性

伟大的篮球队经常因为他们有稳定的控球、精彩的传球、挡不住的投篮而受到赞扬。伟大的音乐家要反复地练习，而且会在一两个音阶或小节上花费数小时的时间。伟大的汽车有许多额外的特性，但是跑得更远，引擎问题更少，而比它们弱小的竞争对手更可靠。所有这些例子都表明，伟大的执行者 “做小事”。

这些小事可能不明显，但是会带来一致而积极的结果。

对于应用程序编程，花里胡哨的用户界面和没有必要的复杂的线程，在保证用户数据正确方面，可不如对用户的冲击那样大。没有什么比在 Web 表单中输入错误的电子邮件地址、电话号码，还要让应用程序傻乎乎地继续执行更糟的了。在这类情况下，真正能够有帮助的小事就是验证。

简而言之，验证就是确保数据正确。这听起来有点傻，但是正确 可能有各种不同的含义，这也正是验证发挥威力的地方。一个正确的电子邮件地址可能只是拥有至少一个 @ 符号，在 @ 符号后有一个句点（.）。但是，更复杂的应用程序可能还要求电子邮件地址是指定长度、来自少数特定域。在任何一种情况下，代码都必须保证输入的数据是可以接受的；否则，就会产生各种可能的错误情况：

◆可能把错误的数据传递到另一个方法，后一个方法不得不执行额外的错误检查，从而降低应用程序的速度。

◆可能把错误的数据传递给一个不 执行错误检测的方法，从而造成应用程序崩溃。

◆可能把错误的数据插入数据库，从而造成下次（可能是 5 分钟或者 5 天以后）读取数据时的错误。

在所有这些情况中，都将给用户带来损害，并给他们提供了转到竞争对手 Web 站点或产品的好理由。

本教程的主题是验证。保证不是什么令人兴奋的、迷人的主题，但是它是可以让好应用程序变成优秀的那些 “小事” 中的一件。

从服务器端验证开始

在 Struts 这样的服务器端编程环境中，最容易的（在某种程度上，也是最自然的）验证方式就是在Java 代码中放几个检测。具体来说，用于从表单接收数据的 Struts Action 似乎是放置验证代码的好地方。可以从 servlet 请求中提取值，并检查电子邮件或电话号码的格式、名称的长度或者邮编的合法性。然后，如果有问题，可以再次向用户显示提交表单，可能还带有错误消息，指出发生的问题。

虽然这可能现在听起来不错，但是执行服务器端验证是获得良好用户体验的最糟方式之一。当用户在 Web 表单上点击 Submit、Save 或 Enter ，并且页面闪烁时（表明服务器上正在发生什么），他们可不想再次回到原来的提交页面，还带着错误消息。如果需要花很长时间来处理请求，那么这个问题就是复杂的：用户必须等待，然后应用程序返回一组错误消息。Web 是种步伐很快的媒体，用户期望最小延迟、响应快的应用程序以及动态的用户界面。

如果不在服务器上处理错误，则应当试着把验证移到客户机。客户端验证可以防止用户提交包含错误数据的表单。因为没有通信的延迟，所以它也更快。现在，好的应用程序中几乎或多或少都有一些客户端验证。

但是，也有些时候服务器端验证 —— 或者至少某种形式的服务器端验证 —— 是有意义的。有时验证包含格式、长度和其他细小问题的检查（想想电话号码、邮编、区号和其他数据）；其他时候，验证要调用更复杂的计算。比如，可能需要确保某本书可以运送到某个邮编的地区。在这些情况下，可能不得不允许服务器请求，因为可能需要数据库和其他复杂处理才能保证正确的响应。但是，用户一般能够理解这些是更复杂的请求，所以一般会耐心等待响应。实际上，这类计算很少被当作验证，而是和应用程序服务的通用业务混在一起。同样，除了这些最复杂的情况之外，只要有可能，都应当把验证移到客户机。