本部分为开发人员提供了为对特定操作或 UI 组件执行验证而实现验证委派 (也称为“验证器”) 所需的信息。
创建 UI 组件验证服务以为
Windchill
客户端提供中心服务,以便对
Windchill
UI 中出现的操作和其他组件执行验证。对服务和结果解释的调用应由版本 9.0 中开发的多个公用组件管理。应用程序开发人员的主要职责是开发验证器类,该类由验证服务调用以验证特定操作或 UI 组件。本文档对编写验证器类的过程和最佳做法进行了概述。
此文档应由负责编写一个或多个验证器的开发人员使用,以确定某一操作或 UI 组件在给定页面或上下文等项目上是否有效。文档应介绍调用验证器时执行的每种验证操作类型的示例。
UI 验证服务中的所有类 (已注明项除外) 均在 com.ptc.core.ui.validation 包中定义。
验证器开发人员无需与此图中的所有类交互 (但可与其中的很多类交互)。此文档将讨论各种类,但在开始时,编写验证器的开发人员应始终定义其验证器类以扩展 DefaultUIComponentValidator。
本部分的读者应全面了解 Java 编程语言,并且还会熟悉
Windchill
解决方案套件。
验证器开发人员需要与公用组件开发人员和验证服务的其他调用方进行协作。为确保服务的调用方将所有数据传递到给定验证器需要执行验证的服务,这种协作必不可少。强烈建议验证器开发人员在该方法的 Javadoc 中包括给定验证方法所需的数据列表。此外,还可以包括此方法说明的验证键 (操作名称) 的列表。例如:
public class DefaultWIPValidator extends DefaultUIComponentValidator
{
…
/**
* This implementation of performLimitedPreValidation will check the checkout
* state of all the Workable objects in the ValidationCriteria's targetObjects
* WTCollection, and base its validation results on whether an object in the
* given state can have the specified action performed on it. (e.g., an object
* in the checked-in state can not have an undo checkout action performed on it)
*
* At a minimum, a caller of this method should provide the targetObjects
* WTCollection in the validationCriteria argument.
*
* The expected validationKey arguments for this method are:
* checkin
* checkout
* undocheckout
*
* <BR><BR><B>Supported API: </B>false
*
* @param validationKey The String identifying the action or component being validated.
* @param validationCriteria Object holding information required to perform validation tasks.
* @param locale The user's Locale. If a <i>null</i> value is passed in, the session locale will be used.
* @return UIValidationResultSet
**/
public UIValidationResultSet performLimitedPreValidation (String validationKey, UIValidationCriteria validationCriteria, Locale locale) throws WTException
{
…
}
…
}
通过将此文档用作参考,开发人员应创建一致的性能验证器。验证服务的调用方应确信其验证的任何操作或 UI 组件都将以一致的方式进行验证。
从术语
validation
的定义开始非常有帮助。出于此讨论的目的,术语
validation
指的是执行的活动,用于确定用户可以查看或执行的操作。例如:
•
是否应显示“创建部件”操作?
•
是否允许检出此对象?
•
用户在此创建向导中输入的所有内容是否均有效?
为了便于讨论,可将
validation
分为三个广义类别:
•
尝试回答问题:“是否应在 UI 中向用户显示内容?如果是,是否应显示可编辑/可选内容?”
•
例如,我们是否应为容器 B 中的用户 A 显示并启用“创建部件”操作?
•
可对操作或其他 UI 组件 (状况符号、属性、表格等) 执行预先验证操作。
选择后验证
•
尝试回答问题:“是否应允许继续执行刚刚在 UI 中选择的操作?”
•
例如,我们是否可以允许检出部件 A、B 和 C?
提交后验证
•
尝试回答问题:“用户刚刚输入的数据有效吗?”
•
例如,当用户在“创建部件”向导中单击“下一步”时,是否让他们转到下一步,或者他们是否需要修改当前步骤中的某些数据 (例如名称、编号等)?
UI 组件 (操作) 验证服务针对以上列出的每种验证类型显示一个或多个 API。