Implementing Pre-Validation Methods
The last two methods you can override in your Validator implementation are performFullPreValidation and performLimitedPreValidation. The methods provide similar functionality, as they are both called by clients wanting to know whether an action (or other UI component) should be enabled, disabled, or hidden in the UI. The intended usage of performLimitedPreValidation is that a client would call it when they want to do a quick check of whether or not an action should appear in the UI. A client calling this method should know that they are not guaranteed that actions will be accurately hidden in all cases – we are sacrificing accuracy in favor of performance. On the other hand, a client would call performFullPreValidation in cases where they want accurate results, at the potential cost of decreased performance.
Some examples of Pre-Validation include:
Example 1:
We are rendering a table in which each row could have action icons for check-out, check-in, revise, or delete. Given the objects in the table, which actions should be enabled in which row?
|
|
In this case, we would probably want to perform limited pre-validation for performance reasons.
|
Example 2:
We are rendering a dropdown list of actions on a doc details page. Given a list of several actions, which ones should be available for this particular doc?
|
|
In this case, we would probably want to perform full pre-validation, since performance is not as much of an issue (only one object, as opposed to several in the first example), and accuracy is more important.
|
The argument list and return types for each Pre-Validation method are identical:
public UIValidationResultSet performFullPreValidation (String
validationKey, UIValidationCriteria validationCriteria,
Locale locale)
public UIValidationResultSet performLimitedPreValidation
(String validationKey, UIValidationCriteria
validationCriteria, Locale locale)
A pseudo-implementation of performFullPreValidation would take the following form:
import com.ptc.core.ui.validation.*;
…
public class MyValidator extends DefaultUIComponentValidator{
…
public UIValidationResultSet performFullPreValidation (String
a_key,
UIValidationCriteria a_criteria, Locale a_locale){
// get required info from UIValidationCriteria
WTContainerRef parentContainer =
a_criteria.getParentContainer();
WTCollection targetObjects = a_criteria.getTargetObjects();
WTPrincipalReference userRef = a_criteria.getUser();
// create result set to return
UIValidationResultSet resultSet = new
UIValidationResultSet();
// iterate through target objects
Iterator targetRefIterator =
targetObjects.referenceIterator();
while (targetRefIterator.hasNext()){
WTReference targetRef =
(WTReference)targetRefIterator.next();
if (we can allow this action to proceed for this object){
resultSet.addResult(new UIValidationResult(a_key,
targetRef,
UIValidationStatus.PERMITTED, null));
}
else{
resultSet.addResult(new UIValidationResult(a_key,
targetRef,
UIValidationStatus.DENIED, new
UIValidationMsg
(localized text,
UIValidationMsgType.INFO)));
}
}
// return the result set
return resultSet
}
}
Pseudo-code for a performLimitedPreValidation would look identical to the example above for performFullPreValidation. The only difference in the actual implementation is that the level of scrutiny used to determine validity may be higher (and less performant) in the full pre-validation example. However, it’s important to note that in practice it’s possible that the limited pre-validation and the full pre-validation checks to be identical (in this case, we would likely be saying that there are no significant performance impacts of performing full pre-validation all the time).
