バリデータに定義する事前検証メソッドには、実際は "制限付き" 事前検証と "完全" 事前検証の 2 つがあります。実装する各メソッドは、performLimitedPreValidation() および performFullPreValidation() と呼ばれます。

制限付き事前検証と完全事前検証を区別するのは、パフォーマンスの考慮が目的です。パフォーマンスを考慮する必要がある場合、クライアントインフラストラクチャは検証サービスに制限付き事前検証の実行を求めます。現在のところ、操作に対する制限付き事前検証が要求されるのは、行レベルの "操作アイコン" がテーブルまたはツリーで事前検証される場合に限られます。属性については、制限付き事前検証が常に要求されます。

バリデータ開発者が、いつ制限付き事前検証を呼び出すか、いつ完全事前検証を呼び出すかを計算する必要はありません。両方のメソッド (performLimitedPreValidation() と performFullPreValidation()) をバリデータに実装しておけば、インフラストラクチャが特定の状態に合わせて適切なメソッドを呼び出します。performLimitedPreValidation() と performFullPreValidation() メソッドがまったく同じロジックを持つことは問題なく、多くの場合そうなっています。

50 行のテーブルがあり、各行に 5 つの行レベルの操作アイコンがあるとします。テーブルがレンダリングされる前に、250 (50 行 × 5 操作) の事前検証チェックが実行され、各行でどの操作を使用可能にするかを決めます。各検証チェックに .01 秒かかるとすると、ページがレンダリングされる前の事前検証だけでも 2.5 秒かかってしまいます。

この場合は、検証の "正確性" よりも "パフォーマンス" を優先することが考えられます。このような場合、クライアントインフラストラクチャは検証サービスに "制限付き" 事前検証の実行を求めます。バリデータは制限付き検証を呼び出したときには "負担の大きい" 検証チェックは行わず、不明な場合は操作を有効にします。

つまり、操作をユーザーに許可するかどうかを判断するためにアクセス許可を確認する必要があるとします。しかし、アクセス許可のチェックには大きな負担がかかります。そこで、バリデータの performLimitedPreValidation() で、アクセス許可のチェックをスキップし、ユーザーが適切なアクセス許可を持つと見なします。最悪でも、ユーザーに操作が表示され、有効であるものの、そのユーザーが操作を起動しようとすると、選択後検証がより詳細なチェックを実行し、ユーザーによる操作の実行を拒否します。これが、制限付き事前検証で "正確性" よりも "パフォーマンス" を優先するという意味です。

一方、テーブル行または情報ページの "ドロップダウン" 操作リストの操作を事前検証するとします。ユーザーがドロップダウンリストを選択した後、(ページが最初にレンダリングされるときと異なり) Ajax を使用して入力しているので、パフォーマンスはあまり問題になりません。いくつかの操作については検証を行いますが、それも単一コンテキストオブジェクトに限られます。

このような場合は、パフォーマンスよりも検証の正確性を優先する方が適切です。制限付き事前検証で説明した同じ例について考えみると、ある操作をユーザーに許可するかどうかを判断するために、アクセス許可のチェックを実行する場合は、バリデータの performFullPreValidation() メソッドでそのチェックを行う負担は許容範囲内となります。チェックには余計に時間がかかるかもしれませんが、ページ (または Ajax コンポーネント) がレンダリングされる前に実行する検証数は処理可能なレベルなので、パフォーマンスの低いチェックも許容できます。

多くの場合、バリデータの performFullPreValidation() と performLimitedPreValidation() メソッドの実装はまったく同一であることに留意してください。