Authoring a Validator Class
Action and UI Component owners will be responsible for writing the Validators that validate those actions and UI components. To create a Validator, you’ll need to create a subclass of com.ptc.core.ui.validation.DefaultUIComponentValidator.java. There are currently five public methods defined in DefaultUIComponentValidator.java. Your subclass can override one to all of them:
performFullPreValidation()
performLimitedPreValidation()
validateFormSubmission()
validateSelectedAction()
validateSelectedMultiSelectAction()
For those methods which you do not override, the default behavior (always enable/permit) will be inherited from the DefaultUIComponentValidator class.
You will also need to create a properties entry to associate your Validator class with a particular validation key (action). The validation service uses these entries to find the right Validator for a given validation key (action). The entry will go in service.properties, or your application team’s service properties file (ask your group lead where you should put your entry), and should have this format:
wt.services/rsc/default/com.ptc.core.ui.UIComponentValidator/<validationKey>/
null/0=com.ptc.my.validators.MyValidator
Where <validationKey> is the validation key for your action/component and the right-side value is the fully-qualified class name of your Validator.
There are three types of checks you should never have to perform in your Validator implementations. These checks are performed by the validation service before the Validators are called. They include:
• Role-based checking (visibility of actions based on input into the RBUI system, which is not to be confused with access control checking, which needs to be done in the Validators.)
• Install-based checking (should an action or UI component be available given the set of solutions installed on a given system?)
• Client-based checking (should an action or UI component be available in a given client, like DTI or PSE?)