基本的なカスタマイズ > ユーザーインタフェースのカスタマイズ > Windchill JSP フレームワークを使用した HTML クライアントのカスタマイズ > 操作とプロパティの検証ロジックの追加 > 実装 > 概要
  
概要
検証 という用語の定義から始めます。この説明では、検証という用語はユーザーが表示または実行することができる内容を確認するために行われるアクティビティを意味します。次に例を示します。
「部品を作成」操作を表示する必要があるか。
このオブジェクトのチェックアウトを許可する必要があるか。
この作成ウィザードにユーザーが入力した内容に問題はないか。
この説明では、検証 は以下の 3 つの大きなカテゴリに分けられます。
事前検証
「UI でユーザーに何かを表示する必要があるか。表示する必要がある場合には、それは編集可能か、選択可能か」という問いに答えます。
たとえば、コンテナ B のユーザー A に対して、「部品を作成」操作を表示して有効にする必要があるかどうかです。
事前検証は、操作またはほかの UI コンポーネント (ステータスグリフ、属性、テーブルなど) に対して実行できます。
選択後検証
「UI で選択された操作の続行を許可する必要があるか」という問いに答えます。
たとえば、部品 A、B、および C のチェックアウトを許可できるかどうかです。
サブミット後検証
「ユーザーが入力したデータは有効か」という問いに答えます。
たとえば、ユーザーが「部品を作成」ウィザードの「次へ」をクリックしたとき、次のステップへの移動を許可するか、それともユーザーが現在のステップの一部のデータ (名前、番号など) を修正する必要があるかどうかです。
UI コンポーネント (操作) 検証サービスは、前述の各タイプの検証に対し、API を公開します。
高いレベルから見ると、共通コンポーネントまたはほかのクライアントが検証サービスの検証 API を呼び出し、1 つまたは複数の検証キー (create など、操作名として考えることができるもの) および UIValidationCriteria ビーンを渡します。このビーンには、検証を実行するために必要でクライアントによって認識されたデータが含まれています。検証サービスでは検証キーを使用して照会を実行し、検証アクティビティを実行するために呼び出す必要のあるバリデータクラスを識別します。次に、サービスはキーおよび UIValidationCriteria を特定されたバリデータに渡し、結果を待機します。バリデータからの結果がある場合、サービスは (結果のバンドルを作成し) クライアントに結果を返します。
このドキュメントではバリデータクラスおよびメソッドの作成に注目します。