There are actually two pre-validation methods defined in a validator – one method is for “limited” pre-validation, and the other is for “full” pre-validation. The respective methods you’ll implement are called performLimitedPreValidation() and performFullPreValidation().

The distinction between limited pre-validation and full pre-validation is made for performance considerations. The client infrastructure will ask the validation service to perform limited pre-validation in situations where performance is essential. Currently, the only scenario when limited pre-validation is requested for actions is when the row-level “action icons” are being pre-validated in a table or tree. For attributes, limited pre-validation is always requested.

As a validator developer, you don’t need to figure out when limited pre-validation is called vs. when full pre-validation is called. You just implement both methods (performLimitedPreValidation() and performFullPreValidation()) in your validator and assume that the infrastructure will call the appropriate method under the given conditions. It’s possible and, in many cases, likely that your performLimitedPreValidation() and performFullPreValidation() methods will have the exact same logic.

Consider a table that has 50 rows, with five row-level action icons in each row. Before the table is rendered, there will be 250 (50 rows x 5 actions) pre-validation checks performed to determine which actions should be available in each row. If each of those validation checks even takes .01 second, that means that 2.5 seconds will be spent on pre-validation alone before the page is even rendered.

In this case, we are willing to sacrifice validation “accuracy” for “performance”. The client infrastructure will request “limited” pre-validation from the validation service in this case. The expectation is that your validator will not perform any “expensive” validation checks when limited pre-validation is invoked, erring on the side of enabling the action.

In other words, suppose that you need to check some access permissions in order to really determine whether or not an action should be available to a user, but you know that access permissions are expensive to check. In your validator’s performLimitedPreValidation() you would skip the access permission check and assume that the user has the appropriate permissions. The worst case scenario is that the action is displayed and enabled for the user, but once they try to invoke it, post-select validation performs a more complete check and denies the user from performing the action. This is what is meant by sacrificing “accuracy” for “performance” in limited pre-validation.

On the other hand, suppose you’re pre-validating an action in a “drop-down” list of actions in a table row, or on an info page. Since we’re using Ajax to populate these dropdown lists once the user selects them (as opposed to when the page is initially rendered), performance is not as critical. At most, we’ll be validating several actions, but only for a single context object.

In this case, it is acceptable to have slower performance in favor of validation accuracy. Considering the same example we described for limited pre-validation, if you need to perform some access permission checking to determine whether or not an action should be available to a user, you can afford to make that check in your validator’s performFullPreValidation() method. It may take longer to perform the check, but since the number of validations being performed before the page (or Ajax component) is rendered is manageable, the less-performant check is acceptable.

Keep in mind that in many situations, your validator’s performFullPreValidation() and performLimitedPreValidation() method implementations will be identical.