A validator ensures that the data in a typed data element conforms to the business rules of the data element's business object. The property descriptor definition for the type specifies the validator. If the property descriptor does not specify a validator, all values for the data element are valid.

To validate data for a type, a validator requires a String or an object of that type. If the passed object is a String, the validator must first convert the String to the type before it can perform the validation. Unless there is a converter identified in a passed conversionType parameter, the validator uses the default converter of owning property descriptor to perform the conversion. For this reason, the property descriptor must have at least one converter of the default category defined. Some types contain data that changes according to the locale. If this is the case, the validator can perform the validation using a specific locale. By default, the toolkit uses its default locale.

You can define parameters for a validator using key-value pairs. For example, a validator for a date type checks whether the value to be validated lies within limits defined by parameters such as lowerLimit and upperLimit. The owning property descriptor can also define these key-value pairs. The validator first looks for the parameters in the owning descriptor before checking its own Hashtable.

The hierarchy of validator classes mirrors the hierarchy of property descriptor classes. In the same way that AbstractPropertyDescriptor is the parent for all property descriptors, AbstractValidator is the parent for all property descriptors and implements the Validation interface. Validators for simple types inherit directly from this abstract super class in a similar way that simple property descriptor classes inherit directly from AbstractPropertyDescriptor. The toolkit provides validators for basic types such as String, Integer, and Float (StringValidator, IntegerValidator, and FloatValidator). These classes are sample implementations of validator for simple types. Depending on application requirements, you may need to extend them or replace them with another implementation.

Validators for compound business objects extending DataCollection (that is, from either KeyedCollection or IndexedCollection) should extend the KCollValidator and IcollValidator provided by the toolkit. These classes extend AbstractValidator. The following diagram shows the relationships between the classes in the converter hierarchy:

Data elements provide a protocol for validating objects based on their concrete descriptor definitions. These definitions include element state and validator properties. The validation process, ultimately performed by the concrete validator implementation, fires an exception when the validation process ends with errors. Element state provides a way for you to define status flags such as isMandatory, isOmitted, isHidden, isReadOnly, and isDisabled. The ElementState interface defines an API to get and set these flags. The toolkit provides a default implementation for the ElementState interface: the DSEElementState class. This class defines a mask of 32 bits in which the toolkit reserves positions 15 to 4 for internal use. The other positions of the 32 bit mask (bits in positions 3 to 0 and 31 to 16) are available to use as status flags for applications that require them. You can replace this implementation if necessary.

The validation process first uses the state attribute of the data element instance to validate the passed data. For example, a null value is not valid if the state attribute of a data field instance has an active mandatory flag. Once the data passes the state validation, the descriptor validates the data according to the type's business rules. If the data fails validation, the process updates the ErrorInfo object of the data element with the error information that the solution may later require. This error information forms a message with a static part and a dynamic part separated by delimiters. For example, the solution may use JSP code to render an HTML page that displays localized error messages for the errors that occurred while validating the incoming data.

The ErrorInfo class extends the com.ibm.btt.base.Hashtable class and maintains information about each error detected while validating a typed data field. This information consists of a key-value pair in which the key is a String that identifies a detected error and the value is a String that gives a default detailed explanation of the error. To localize this information, each supported locale has a types.properties and a typesext.properties file that contains localized error messages (see NLS).