解决方案
• 预先验证 - 用于确定业务逻辑特定于单个操作或属性，还是同一逻辑适用于多个操作或属性。如果逻辑特定于单个 UI 组件 (操作或属性)，则将逻辑添加到验证器中。如果逻辑可应用于多个 UI 组件，则将逻辑添加到筛选器中。最后，将验证器或筛选器与 UI 组件相关联，以确保将业务逻辑应用于该组件。
◦ 验证器中的预先验证 - 在验证器中实现 performFullPreValidation() 和 performLimitedPreValidation() 方法，以包含所需的业务逻辑。
◦ 筛选器中的预先验证 - 在筛选器中实现 preValidateAction 方法以包含所需的业务逻辑。
• 选择后验证 - 在验证器中执行 validateSelectedAction() 和 validateSelectedMultiSelectAction() 方法以定义所需的业务逻辑，并将验证器与该操作关联。
• 提交后验证 - 在验证器中执行 validateFormSubmission() 方法以定义所需的业务逻辑，并将验证器与向导步骤或整个向导相关联。
必备知识
要实现此目标，需要了解以下内容：
• Windchill 客户端体系结构中的操作框架。
• 应用程序上下文或 service.properties 机制用于注册委派。
• 了解 NmCommandBean 及其方法的基本情况将会有所帮助。
• 实际上，验证服务的应用非常广泛。它不会为您提供用于确定事物是否有效所需的 API。服务将为您的验证器或筛选器提供确定 UI 组件是否有效所需的上下文数据和表单数据。但是，您需要了解如何处理这些数据才能应用您的验证业务逻辑。
解决方案元素
除了在 UI 验证中涉及的解决方案元素外，本节还包含一些关键术语的定义 (以粗斜体显示)。
|
元素
|
类型
|
说明
|
|---|---|---|
|
StandardUIComponentValidation 服务
|
Java 类
|
通常称为验证服务。此服务类用于控制 UI 验证。它接收来自客户端基础结构的验证请求，并委派到相应验证器和筛选器以获得验证结果。然后，它会将验证结果传递回客户端基础结构。
自定义者和应用程序开发人员不必直接与此类进行交互。
|
|
UIValidationKey
|
Java 类
|
通常称为验证键。UIValidationKey 用于标识正在验证的 UI 组件。可以视为 UIValidationKey 与操作或属性具有一一对应关系。
|
|
UIValidationCriteria
|
Java 类
|
通常指的是验证条件。
UIValidationCriteria 是一个 bean 类，其中包含通过验证服务从客户端基础结构传递至验证器和筛选器的上下文 (请求、会话) 数据。
UIValidationCriteria 中大部分内容将直接从 NmCommandBean 中获取，尽管这些对象通常以 WTReferences 返回，而不是 NmOids。
|
|
UIValidationResult
|
Java 类
|
通常称为验证结果。
UIValidationResult 表示一个验证单位。换句话说，它将验证状况与 UI 组件 (操作或属性) 相关联。对多个对象的相同操作执行验证时，可将 UIValidationResult 与每个对象相关联。
|
|
UIValidationResultSet
|
Java 类
|
通常称为结果集。
UIValidationResultSet 只是 UIValidationResult 对象的集合。同时执行多个验证时，将使用结果集。例如，如果验证器对多个对象的相同操作执行预先验证检查，则可以将每个对象的验证结果聚合到 UIValidationResultSet 中。
|
|
UIValidationStatus
|
Java 类
|
通常称为验证状况。
此枚举用于确定 UI 组件是否应在 UI 中显示以及如何显示。例如，有一些值将指示应隐藏某一操作、应禁用某一操作或应启用某一操作。
|
|
UIValidationFeedbackMsg
|
Java 类
|
通常称为反馈消息。
此消息可与验证结果关联。它仅用于选择后验证和提交后验证。与预先验证的验证结果关联的任何反馈消息都将被忽略。
反馈消息可以关联不同的反馈类型 (FeedbackType.java)，例如，用于指明其是错误消息、警告消息还是信息性消息。
|
|
UIComponentValidator
|
Java 接口
|
这是所有验证器实现都需要实现的接口。但是，验证器不应直接实现此接口。相反，它们应扩展 DefaultUIComponentValidator。
每个 UI 组件可以有零个或一个与其关联的验证器。通常，验证器将包含特定于单个 UI 组件的逻辑。对于适用于多个 UI 组件的更通用验证逻辑，通常使用筛选器。
验证服务将调用这些验证器来确定特定 UI 组件的验证状况。
自定义者和应用程序开发人员不必直接与此类进行交互。
|
|
DefaultUIComponentValidator
|
Java 类
|
这是 UIComponentValidator 接口的默认实现。所有验证器实现都应扩展此类。
|
|
ValidationFilter
|
Java 接口
|
这是所有筛选器实现都需要实现的接口。但是，筛选器不应直接实现此接口。相反，它们应扩展 DefaultSimpleValidationFilter 或 DefaultUniversalValidationFilter。
每个 UI 组件都可以有零到多个与其关联的筛选器。通常，筛选器将包含可应用于多个 UI 组件的通用验证逻辑。对于特定于单个 UI 组件或小型 UI 组件集的验证逻辑，通常会使用验证器。
筛选器分为两种类别：简单筛选器和通用筛选器。简单筛选器需要逐个应用到组件。换句话说，您必须选取要将简单筛选器中的逻辑应用到的 UI 组件。相反，通用筛选器将应用于所有 UI 组件，这意味着您必须选择通用筛选器中的逻辑不会应用到哪些 UI 组件。
验证服务将调用 Filtersare 来确定特定 UI 组件的验证状况。
自定义者和应用程序开发人员不必直接与此类进行交互。
|
|
SimpleValidationFilter
|
Java 接口
|
这是所有简单筛选器实现都需要实现的接口。但是，简单筛选器不应直接实现此接口。相反，它们应扩展 DefaultSimpleValidationFilter。
自定义者和应用程序开发人员不必直接与此类进行交互。
|
|
UniversalValidationFilter
|
Java 接口
|
这是所有通用筛选器实现都需要实现的接口。但是，通用筛选器不应直接实现此接口。相反，它们应扩展 DefaultUniversalValidationFilter。
自定义者和应用程序开发人员不必直接与此类进行交互。
|
|
DefaultSimpleValidationFilter
|
Java 类
|
这是 SimpleValidationFilter 接口的默认实现。所有简单筛选器实现都应扩展此类。
|
|
DefaultUniversalValidationFilter
|
Java 类
|
这是 UniversalValidationFilter 接口的默认实现。所有通用筛选器实现都应扩展此类。
|
|
UIComponentSolutionGroup
|
Java 接口
|
这是所有解决方案组实现都需要实现的接口。
解决方案组是一种特殊类型的验证器，用于基于已安装的解决方案进行预先验证。例如，如果给定操作应该在未安装 Windchill ProjectLink 的情况下不可用，则应在解决方案组中定义该逻辑。
|
|
*actions.xml
|
XML 文件
|
actions.xml 文件有多个包含操作定义的 "satellite" 版本 (通常每个模块一个)。
在这些文件中，我们还可将操作配置为包括简单筛选器，而排除通用筛选器。
|
|
*service.properties.xconf
|
XConf 文件
|
service.properites.xconf 文件有多个包含类委派注册表项的 "satellite" 版本 (通常每个模块一个或多个)。
可在这些文件中注册验证器、筛选器和解决方案组，以便指示验证服务应该在何处查找它们。
|
预先验证序列
预先验证序列从客户端基础结构开始 (通常为 StandardNmActionService，但并不绝对) 向验证服务发送 UI 组件列表。预期验证服务将针对每个 UI 组件返回一个指示 UI 组件显示状况的验证结果。每个 UI 组件由一个验证键表示。此外，还需要客户端基础结构将上下文 (会话、请求或表单) 数据传递到验证条件对象内的验证服务。
键 |
|---|
1. 客户端基础结构调用验证服务，将操作 (由验证键表示) 相应传递至要呈现的页面和上下文数据 (由验证条件实例表示)。 |
验证服务从客户端基础结构接收到验证请求后，它会遍历每个验证键，并执行几个任务以确定每个键的验证状况。
验证服务为此执行的第一个任务是：根据所安装的 PTC 解决方案查看给定验证键是否表示一个应隐藏的组件。这通过引用验证服务首次启动时所创建的无效验证键的缓存来完成。要创建缓存，验证服务只需调用所有已注册的解决方案组，并根据已安装的解决方案从每个方案中请求无效验证键的列表。
如果基于解决方案的无效键的缓存包含当前验证键，则验证服务会将组件的状况设置为“隐藏”，且不会对该组件执行任何其他验证。否则，如果基于解决方案的无效键的缓存不包含当前验证键，则验证服务将继续进行其预先验证检查。
键 |
|---|
1. 客户端基础结构调用验证服务，将操作 (由验证键表示) 相应传递至要呈现的页面和上下文数据 (由验证条件实例表示)。 2. 对于每个验证键，验证服务都会执行一系列任务以确定该键的验证状况。任务按以下顺序执行： a. 检查验证键是否位于已安装的解决方案集的无效键列表中。 |
验证服务执行的第二个验证前检查是查看组件是否已被基于角色的 UI 服务隐藏或禁用。基于角色的 UI 服务在 8.0 中引入，作为管理员用户根据用户角色配置 UI 组件显示的一种方式。9.0 中引入 UI 验证服务后，基于角色的 UI 服务已成为 UI 验证服务的特殊委派。
如果基于角色的 UI 服务返回状况“隐藏”或“禁用”，则验证服务会相应地设置组件的状况，而不会对该组件执行任何其他验证。否则，如果基于角色的 UI 服务返回“启用”状况，则验证服务将继续执行其预先验证检查。
键 |
|---|
1. 客户端基础结构调用验证服务，将操作 (由验证键表示) 相应传递至要呈现的页面和上下文数据 (由验证条件实例表示)。 2. 对于每个验证键，验证服务都会执行一系列任务以确定该键的验证状况。任务按以下顺序执行： a. 检查验证键是否位于已安装的解决方案集的无效键列表中。 b. 检查基于角色的 UI 服务是否已配置为禁用或隐藏组件。 |
假设基于角色的 UI 服务指示应启用该组件，则验证服务接下来将检查是否有任何筛选器与 UI 组件相关联。
为确定应将哪些筛选器应用于 UI 组件，验证服务将参考第一次启动验证服务时存储的其他缓存数据。所引用的第一个缓存包含所有已注册的通用筛选器的列表。当筛选器定义并注册为通用筛选器时，默认情况下，它会自动应用于所有 UI 组件。如果在此缓存中找到任何通用筛选器，则会自动将其添加到将应用于给定 UI 组件的筛选器列表中。
尽管默认情况下通用筛选器适用于所有 UI 组件，但支持通过对操作进行配置来忽略单个通用筛选器。(目前，未提供通过配置属性来忽略通用筛选器的类似支持，这意味着任何通用筛选器都将始终应用于所有属性。)如果要配置某一操作来忽略通用筛选器，可在 actions.xml 文件中的操作定义中完成。启动验证服务后，将创建第二个缓存，其中包含操作映射以及其配置为忽略的任何通用筛选器。如果在此缓存中找到给定操作的条目，则应忽略的通用筛选器将从要应用于 UI 组件的筛选器列表中移除。
最后，验证服务会参考第三个缓存，以确定应用于 UI 组件的任何其他筛选器。第三个缓存是将操作与简单筛选器关联的映射。定义并注册为简单筛选器的筛选器必须与某一操作显式关联，才能应用于任何操作。(目前，不支持将简单筛选器与属性关联。)如果要配置某一操作来使用简单筛选器，可在 actions.xml 文件中的操作定义中完成。启动验证服务时，将创建操作的第三个缓存和关联的简单筛选器。
要汇总验证服务确定应将哪些筛选器应用于给定 UI 组件时使用的算法，可以使用以下公式：
每个组件的筛选器数 = 所有通用筛选器 - 忽略的通用筛选器 + 关联的简单筛选器
筛选器列表建立后，验证服务会调用每个筛选器来确定 UI 组件的验证状况。请注意，这不能保证筛选器的调用顺序。如果任何筛选器返回的验证状况为“隐藏”或“禁用”，则验证服务会相应地设置该组件的状况，而不会对该组件执行任何其他验证。否则，如果应用于给定 UI 组件的所有筛选器均返回“启用”状况，则验证服务将继续执行其预先验证检查。
键 |
|---|
1. 客户端基础结构调用验证服务，将操作 (由验证键表示) 相应传递至要呈现的页面和上下文数据 (由验证条件实例表示)。 2. 对于每个验证键，验证服务都会执行一系列任务以确定该键的验证状况。任务按以下顺序执行： a. 检查验证键是否位于已安装的解决方案集的无效键列表中。 b. 检查基于角色的 UI 服务是否已配置为禁用或隐藏组件。 c. 检查与 UI 组件关联的任何筛选器是否指示应禁用或隐藏该组件。 |
(有关其他详细信息，请参阅以下页面上的图表。)如果所有筛选器均未指示应禁用或隐藏 UI 组件，则验证服务针对给定 UI 组件执行的最终检查将检查是否存在与 UI 组件关联的验证器。
将验证器与 UI 组件关联的方法是：在 service.properties.xconf 文件中创建一个条目，该条目将操作 ID (对于操作) 或描述符 ID (对于属性) 链接到应该用于该组件的验证器类的类名称。
如果 UI 组件未注册任何验证器，则会启用该组件。否则，如果存在与 UI 组件关联的验证器，则验证服务将调用该验证器来获取 UI 组件的验证状况。
键 |
|---|
1. 客户端基础结构调用验证服务，将操作 (由验证键表示) 相应传递至要呈现的页面和上下文数据 (由验证条件实例表示)。 2. 对于每个验证键，验证服务都会执行一系列任务以确定该键的验证状况。任务按以下顺序执行： a. 检查验证键是否位于已安装的解决方案集的无效键列表中。 b. 检查基于角色的 UI 服务是否已配置为禁用或隐藏组件。 c. 检查与 UI 组件关联的任何筛选器是否指示应禁用或隐藏该组件。 d. 如果存在与 UI 组件相关联的验证器，则会从验证器获取验证状况。 |
(有关其他详细信息，请参阅以下页面上的图表。)此时，验证服务已完成对每个 UI 组件的验证检查。如果客户端基础结构将单个 UI 组件传递给验证服务以进行预先验证，则验证服务将向调用程序返回单个验证结果。如果将多个 UI 组件传递至验证服务以进行预先验证，则验证服务会将每个组件的验证结果组织为验证结果集，其中每个 UI 组件都包含一个结果。然后，会将验证结果集返回到调用程序。
键 |
|---|
1. 客户端基础结构调用验证服务，将操作 (由验证键表示) 相应传递至要呈现的页面和上下文数据 (由验证条件实例表示)。 2. 对于每个验证键，验证服务都会执行一系列任务以确定该键的验证状况。任务按以下顺序执行： a. 检查验证键是否位于已安装的解决方案集的无效键列表中。 b. 检查基于角色的 UI 服务是否已配置为禁用或隐藏组件。 c. 检查与 UI 组件关联的任何筛选器是否指示应禁用或隐藏该组件。 d. 如果存在与 UI 组件相关联的验证器，则会从验证器获取验证状况。 3. 将验证结果或验证结果集返回到客户端基础结构。 |
选择后验证序列
从概念可以看出，选择后验证会在用户调用 UI 中的某项操作后立即进行。不过，实际上，选择后验证将在目标页面呈现后进行。也就是说，begin.jspf (在 Windchill 客户端体系结构中编写的每个 JSP 页面中都包含此代码) 中提供的逻辑将在实际呈现页面之前调用验证服务以确定是否应呈现该页面。
验证器是用于选择后验证逻辑的唯一接受位置。与预先验证不同，不会与解决方案组、基于角色的 UI 服务或用于选择后验证的筛选器进行交互。因此，选择后验证序列比预先验证序列简单得多。
首先，客户端基础结构调用验证服务，传递对应于正在呈现的页面的操作 (此操作由验证键表示)。客户端基础结构会与操作一起以验证条件实例的形式传递上下文数据。
键 |
|---|
1. 客户端基础结构调用验证服务，将操作 (由验证键表示) 相应传递至要呈现的页面和上下文数据 (由验证条件实例表示)。 |
从客户端基础结构接收到选择后验证请求后，验证服务将检查是否存在与指定操作关联的验证器。
与预先验证一样，通过在 service.properties.xconf 文件中创建一个条目将验证器与操作相关联，其中该条目会将操作 ID 链接到该操作的验证器类的类名称。
如果没有针对操作注册任何验证器，则允许用户执行该操作。否则，如果存在与操作关联的验证器，则验证服务将调用该验证器来获取操作的验证状况。
键 |
|---|
1. 客户端基础结构调用验证服务，将操作 (由验证键表示) 相应传递至要呈现的页面和上下文数据 (由验证条件实例表示)。 2. 验证服务将检查是否存在与操作关联的验证器。如果存在，它将调用验证器以获取操作的验证状况 (允许或拒绝)。 |
验证器返回其验证结果后，验证服务仅会将验证器返回的验证结果传递到客户端基础结构。客户端基础结构将检查该状况为“允许”还是“拒绝”。如果状况为“允许”，则显示页面或向导。如果状况为“拒绝”，则会将用户重定向到上一页面，并且如果验证器返回一条指示操作被拒绝原因的消息，则会向用户显示该消息。
键 |
|---|
1. 客户端基础结构调用验证服务，将操作 (由验证键表示) 相应传递至要呈现的页面和上下文数据 (由验证条件实例表示)。 2. 验证服务将检查是否存在与操作关联的验证器。如果存在，它将调用验证器以获取操作的验证状况 (允许或拒绝)。 3. 验证服务会将验证状况 (封装在验证结果中) 从验证器传递至客户端基础结构，这可显示目标页面/向导，或使用户返回到调用该操作的页面。 |
提交后验证序列
用户在向导中从一个步骤导航到另一步骤或者用户提交整个向导时，会进行提交后验证。
验证器是提交后验证逻辑的唯一接受位置，与预先验证不同，它不会与解决方案组、基于角色的 UI 服务进行交互，也不会针对提交后的验证执行筛选。因此，提交后验证序列比预先验证序列简单得多。实际上，它与选择后验证序列几乎相同。
首先，客户端基础结构调用验证服务，传递与“下一步”或“确定”向导操作关联的 ID (此 ID 由验证键表示)。客户端基础结构会与验证键一起以验证条件实例的形式传递上下文数据。
键 |
|---|
1. 客户端基础结构调用验证服务，传递与向导的“下一步”或“确定”操作 (由验证键表示) 关联的 ID 以及上下文数据 (由验证条件实例表示)。 |
接收到来自客户端基础结构提交后验证请求后，验证服务将检查是否存在与向导的“下一步”或“确定”操作关联的验证器。
与预先验证和选择后验证一样，通过在 service.properties.xconf 文件中创建一个条目将验证器与向导的“下一步”或“确定”操作相关联，其中该条目会将操作 ID 链接到该操作的验证器类的类名称。
如果没有针对操作注册任何验证器，则允许用户移动到下一步或提交整个向导。否则，如果存在与“下一步”或“确定”操作关联的验证器，则验证服务将调用该验证器来获取操作的验证状况。
键 |
|---|
1. 客户端基础结构调用验证服务，传递与向导的“下一步”或“确定”操作 (由验证键表示) 关联的 ID 以及上下文数据 (由验证条件实例表示)。 2. 验证服务检查是否存在与“下一步”或“确定”操作关联的验证器。如果存在，它将调用验证器以获取操作的验证状况 (允许或拒绝)。 |
验证器返回其验证结果后，验证服务仅会将验证器返回的验证结果传递到客户端基础结构。客户端基础结构将检查该状况为“允许”还是“拒绝”。如果状况为“允许”，则允许用户继续执行向导中的下一步，或完成向导的提交。如果状况为“拒绝”，则会限制用户移至下一个向导步骤和提交向导，并且如果验证器返回一条指示操作被拒绝原因的消息，则会向用户显示该消息。
键 |
|---|
1. 客户端基础结构调用验证服务，将操作 (由验证键表示) 相应传递至要呈现的页面和上下文数据 (由验证条件实例表示)。 2. 验证服务检查是否存在与“下一步”或“确定”操作关联的验证器。如果存在，它将调用验证器以获取操作的验证状况 (允许或拒绝)。 3. 验证服务会将验证状况 (封装在验证结果中) 从验证器传递至客户端基础结构，这可以允许用户继续执行向导中的下一步或提交整个向导，或将用户返回到调用该操作的向导步骤。 |