事前検証シーケンスは、最初にクライアントインフラストラクチャ (通常 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 つの結果が収められています。その後、検証結果セットが呼び出し側に戻されます。