この目的を達成するには、次のことを理解している必要があります。

UI 検証に関連するソリューションエレメントのほかに、このセクションでは主な用語 (太字) の定義についても説明します。

事前検証シーケンスは、最初にクライアントインフラストラクチャ (通常 StandardNmActionService ですが例外もあります) が UI コンポーネントを検証サービスに送ります。すると、検証サービスが各 UI コンポーネントに対する検証結果を返し、UI コンポーネントの表示ステータスを示します。各 UI コンポーネントは検証キーで表されます。また、クライアントインフラストラクチャがコンテキスト (セッション、リクエスト、またはフォーム) データを検証基準オブジェクト内の検証サービスに渡します。

検証サービスがクライアントインフラストラクチャから検証リクエストを受け取ると、検証サービスは各検証キーを反復して一連のタスクを実行し、各キーの検証ステータスを決定します。

検証サービスが実行する最初のタスクは、インストールされている PTC ソリューションに基づいて、対象となる検証キーが非表示にすべきコンポーネントに該当するかどうかを調べることです。これを行うには、検証サービスを最初に開始したときに作成される、無効な検証キーのキャッシュを参照します。キャッシュを作成するには、研修サービスがすべての登録済みソリューショングループを呼び出し、インストールされているソリューションに基づいて、各々に対して無効な検証キーを要求するだけです。

無効なソリューションベースのキーのキャッシュに現在の検証キーが含まれる場合、検証サービスはコンポーネントのステータスを "非表示" に設定し、そのコンポーネントに対してはその他の検証を行いません。一方、無効なソリューションベースのキーのキャッシュに現在の検証キーが含まれない場合は、検証サービスによる事前検証チェックが続行します。

2 番目の事前検証チェックでは、コンポーネントが役割ベースの UI サービスによって非表示または無効に設定されているかどうかを調べます。役割ベースの UI サービスは、管理者ユーザーがユーザーロールに基づいて UI コンポーネントの表示を設定する方法として、バージョン 8.0 で導入されました。バージョン 9.0 の UI 検証サービスの導入により、役割ベースの UI サービスは UI 検証サービスの特別代理となりました。

役割ベースの UI サービスが "非表示" または "無効" ステータスを返すと、検証サービスはそれに合わせてコンポーネントのステータスを設定し、そのコンポーネントに対してはその他の検証を行いません。一方、役割ベースの UI サービスが "有効" ステータスを返すと、検証サービスは事前検証チェックを続行します。

役割ベースの UI サービスにより、コンポーネントを有効とするように設定されている場合、検証サービスは次に、UI コンポーネントに関連付けられているフィルタがあるかどうかを確認します。

どのフィルタを UI コンポーネントに適用するかを判断するために、検証サービスは最初に検証サービスが開始したときに保存されたその他のキャッシュデータを参照します。参照した最初のキャッシュに、すべての登録済みユニバーサルフィルタのリストが含まれます。フィルタがユニバーサルフィルタとして定義され、登録されている場合は、デフォルトで自動的にすべての UI コンポーネントに適用されます。このキャッシュに既成のユニバーサルフィルタが 1 つでも存在する場合は、対象となる UI コンポーネントに適用されるフィルタリストに自動的に追加されます。

ユニバーサルフィルタはデフォルトですべての UI コンポーネントに適用されますが、個別にユニバーサルフィルタを無効にする操作を設定することができます(現在のところ、同じようにユニバーサルフィルタを無効にする属性の設定はサポートしていません。つまり、ユニバーサルフィルタは例外なくすべての属性に適用されます)。ユニバーサルフィルタを無視する操作を設定するには、actions.xml ファイルの操作定義を使用します。検証サービスが開始すると、操作マップと無視の設定をしたユニバーサルフィルタが入った 2 番目のキャッシュが作成されます。このキャッシュに対象となる操作のエントリが見つかった場合は、無視すべきユニバーサルフィルタが UI コンポーネントに適用されるフィルタリストから除去されます。

最後に、検証サービスは 3 番目のキャッシュを参照し、UI コンポーネントに適用すべきその他のフィルタを確認します。この 3 番目のキャッシュは、操作をシンプルフィルタに関連付けるマップです。シンプルフィルタと定義され、登録されたフィルタを操作に適用するには、明示的にその操作と関連付ける必要があります(現在のところ、シンプルフィルタと属性との関連付けはサポートしていません)。シンプルフィルタを使用する操作を設定するには、actions.xml ファイルの操作定義を使用します。検証サービスを開始したときに、この操作の 3 番目のキャッシュと、関連付けられたシンプルフィルタが作成されます。

要するに、検証サービスが対象となる UI コンポーネントに対してどのフィルタを適用するかを決定するのに使用されるアルゴリズムは、以下の式で表されます。

コンポーネントごとのフィルタ = すべてのユニバーサルフィルタ - 無視されたユニバーサルフィルタ + 関連付けられたシンプルフィルタ

フィルタリストを確立すると、検証サービスは各フィルタを呼び出して、UI コンポーネントの検証ステータスを決定します。フィルタが呼び出される順序は保証されないことに注意してください。フィルタが "非表示" または "無効" の検証ステータスを返すと、検証サービスはそれに合わせてコンポーネントのステータスを設定し、そのコンポーネントに対してはその他の検証を行いません。一方、その UI コンポーネントに適用されるすべてのフィルタが "有効" ステータスを返すと、検証サービスは事前検証チェックを続行します。

(詳細については、次のページの図を参照してください)。UI コンポーネントを無効または非表示にするように設定されているフィルタがまったくない場合は、その UI コンポーネントに対して関連付けられているバリデータがあるかどうかの最終チェックが実行されます。

バリデータは UI コンポーネントに関連付けられます。これは、action id (操作の場合) または descriptor id (属性の場合) とそのコンポーネントに使用するバリデータクラスのクラス名をリンクするエントリを service.properties.xconf ファイルに作成することによって行います。

その UI コンポーネントに登録されているバリデータがない場合は、コンポーネントは有効となります。一方、UI コンポーネントに関連付けられたバリデータがある場合は、検証サービスがそのバリデータを呼び出し、その UI コンポーネントの検証ステータスを取得します。

(詳細については、次のページの図を参照してください)。この時点で、検証サービスは各 UI コンポーネントの検証チェックを完了しています。事前検証でクライアントインフラストラクチャが単一の UI コンポーネントを検証サービスに渡した場合、検証サービスは単一の検証結果を呼び出し側に戻します。また、事前検証で複数の UI コンポーネントが検証サービスに渡された場合は、検証サービスが各コンポーネントの検証結果を 1 つの検証結果セットにまとめます。検証結果セットには、UI コンポーネントごとに 1 つの結果が収められています。その後、検証結果セットが呼び出し側に戻されます。

概念的には、選択後検証はユーザーが UI で操作を起動した直後に発生します。ただし実際には、選択後検証はターゲットページがレンダリングされたときに実行されます。つまり、begin.jspf (Windchill クライアントアーキテクチャで作成されたすべての JSP ページに含まれるコード) に、検証サービスを呼び出し、実際に開始する前にページのレンダリングが適切かどうかを判断するというロジックがあります。

選択後検証ロジックで許可される唯一の場所がバリデータです。事前検証と異なり、選択後検証にはソリューショングループ、役割ベースの UI サービス、またはフィルタとのやり取りはありません。このため、選択後検証のシーケンスは事前検証よりもはるかに単純です。

最初に、クライアントインフラストラクチャが検証サービスを呼び出します。サービスは、レンダリングされるページに対応する操作 (この操作は検証キーで表されます) を渡します。また操作とともに、コンテキストデータも検証基準インスタンスの形式で渡します。

クライアントインフラストラクチャから選択後検証リクエストを受け取った後、検証サービスは指定した操作と関連付けられているバリデータがあるかどうかを確認します。

バリデータは、事前検証と同様に、action id とその操作のバリデータクラスのクラス名をリンクするエントリを service.properties.xconf ファイルに作成することで操作に関連付けられます。

その操作に登録されているバリデータがない場合、ユーザーは操作の実行を許可されます。一方、操作に関連付けられたバリデータがある場合は、検証サービスがそのバリデータを呼び出し、その操作の検証ステータスを取得します。

バリデータが検証結果を返した後、検証サービスが行うのは、バリデータから返された検証結果をクライアントインフラストラクチャに渡すことです。ステータスが許可か拒否かにかかわらず、クライアントインフラストラクチャは確認を行います。ステータスが "許可" の場合は、ページまたはウィザードが表示されます。ステータスが "拒否" の場合、ユーザーは前のページにリダイレクトされます。また、バリデータが操作の拒否理由を示すメッセージを返した場合は、そのメッセージがユーザーに表示されます。

サブミット後検証は、ユーザーがウィザードの 1 つのステップから次のステップに移動するとき、またはユーザーがウィザード全体をサブミットするときに発生します。

サブミット後検証ロジックで唯一許可される場所がバリデータです。事前検証と異なり、サブミット後検証にはソリューショングループ、役割ベースの UI サービス、またはフィルタとのやり取りはありません。このため、サブミット後検証のシーケンスは事前検証よりもはるかに単純です。選択後検証のシーケンスとほとんど同じです。

最初に、クライアントインフラストラクチャが検証サービスを呼び出します。サービスは、"次へ" または "OK" ウィザード操作 (この id は検証キーで表されます) に関連付けられた id を渡します。また検証キーとともに、コンテキストデータも検証基準インスタンスの形式で渡します。

クライアントインフラストラクチャからサブミット後検証リクエストを受け取った後、検証サービスはウィザードの "次へ" または "OK" 操作と関連付けられているバリデータがあるかどうかを確認します。

バリデータは、事前検証や選択後検証と同様に、action id とその操作のバリデータクラスのクラス名をリンクするエントリを service.properties.xconf ファイルに作成することで、ウィザードの "次へ" または "OK" 操作に関連付けられます。

その操作に登録されているバリデータがない場合、ユーザーは次のステップへの移動またはウィザード全体のサブミットを許可されます。一方、"次へ" または "OK" 操作に関連付けられたバリデータがある場合は、検証サービスがそのバリデータを呼び出し、その操作の検証ステータスを取得します。

バリデータが検証結果を返した後、検証サービスが行うのは、バリデータから返された検証結果をクライアントインフラストラクチャに渡すことです。ステータスが許可か拒否かにかかわらず、クライアントインフラストラクチャは確認を行います。ステータスが "許可" の場合、ユーザーは次のステップへの移動、またはウィザード全体のサブミットが許可されます。ステータスが "拒否" の場合、ユーザーは次のウィザードステップへの移動またはウィザードのサブミットが禁止され、バリデータが操作の拒否理由を示すメッセージを返した場合は、そのメッセージがユーザーに表示されます。