怀疑论者的JSF - JSF转换与验证 - 编程入门网

JSF 用 validateEmail 方法对绑定到 user.email 模型属性的 inputText 组件值进行自定义验证。如果电子邮件格式无效，那么就在相关组件的 faces 上下文中添加消息。考虑到这种验证方法实际上是 backing bean 的一部分，为什么通常必须用某个值与相关组件的关联来评估该值，而不是直接检查本地 bean 属性呢？线索就在前面的生命周期图中。如果现在不能马上找到答案，也不要担心，我们将在本文的最后对此加以说明。

默认验证

注意上面 email 标签的 required 属性。利用 required 属性是一种默认 验证形式。如果这个属性是 true，那么相应的组件必须有一个值。一个重要的说明：如果 required 属性为 false，那么就不用对这个标签/组件指派验证，这样，JSF 将跳过对这个组件的验证，并让值和组件的状态保持不变。

图 13 概述了我们讨论过的验证形式。

图 13. 验证视图

自定义消息

您可能注意到了，JSF 提供的默认转换和验证消息非常长，这会让那些总是输入无效表单数据的最终用户感到困惑和恼火。幸运的是，您可以通过创建自己的消息资源绑定来改变 JSF 提供的默认消息。jsf-impl.jar （或类似的文件中）中包含了一个 message.properties 文件，该文件包含图 14 所示的默认消息。

图 14. 默认 JSF 转换和验证消息

怀疑论者的JSF - JSF转换与验证(11)

通过创建自己的 message.properties 文件并断开指定场所的 faces 上下文中绑定的消息资源，您可以更改默认消息，如图 15 所示。

图 15. 取消消息资源绑定

关于在 JSF 中创建自定义转换和验证消息的更多内容请参前阅 参考资料。

处理 JSF 生命周期

我们在本文前面留下了一些问题让您考虑，现在可以解决它们了！我们提到的一件事是对 UICommand 按钮使用 immediate 属性，比如 commandLink 或者 commandButtons。现在请您考虑希望在什么样的场景中跳过验证。

基本上只要用户需要输入数据，就需要对这个数据进行验证。不过，如果整个数据项是可选的，那么就不需要进行验证。一种避免 JSF 生命周期的验证阶段的方法是利用 UICommand 组件的 immediate 属性，该属性可以在处理验证阶段之前 的应用请求值阶段期间（而不是在处理验证阶段 之后 的调用应用程序阶段）强制调用这个操作。

immediate 属性允许您通过标准浏览规则控制页流程，并绕过验证。可以针对特定的场景实现这项技术，比如带有可选步骤和/或表单的在线向导（如当用户单击 Skip 按钮以进入下一视图），或者在用户因为某种原因而取消某个表单的情况下。

我们在本文中留下的第二个问题是：既然验证方法实际上是 backing bean 的一部分，那么为什么通常必须利用组件关联来判断它的值。请参阅前面的 JSF 应用程序生命周期，看看您能否找到答案。

这里的密诀是：尽管 validateEmail 嵌入验证方法是实际的 backing bean 的一部分，但是该方法必须通过组件关联来引用这，而不是直接访问本地属性来引用值。由于验证发生在组件值绑定到模型之前（在更新模型值阶段），所以模型处于未知状态。因此，必须编写嵌入自定义验证逻辑，就像使用一个自定义 Validator 对象处理验证一样。这也解释了维护相同方法签名的需求。

这些尚待解决的枝节问题有什么意义呢，当然，它们最终将我们带回 JSF 应用程序生命周期。将这些问题汇总在一起，就能体现充分理解生命周期的重要性 —— 向后、向前或由内向外，这样您就可以在需要的时候操纵它。

结束语

在本文中我们讨论了相当多的 JSF 转换和验证的基本内容。事实上，我们讨论了在自己的应用程序中使用这些过程需要知道的大部分内容（至少对这个版本

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!