This recipe just elaborated on how to build two of the most important layers of Spring MVC applications: the validator and type conversion engine components. Once installed and properly configured, these two components are the first ones to intercept the incoming request parameters, which are all strings by object type.

Before the modelAttribute reaches the controller, PropertyEditors, whether built-in or custom, convert first the textual request data to their respective object types during <form:form> binding. A PropertyEditor is a JavaBeans API, famous in the Spring framework for converting modelAttribute property values to and from string values. Its setAsText() converts the parameters to the desired type, while its getAsText() method initializes the form through the modelAttribute once the form is loaded.

Each built-in PropertyEdior manages the conversion per valid Spring type, while CustomPropertyEditor handles one or more conversions of complex or custom types. Although there is a built-in PropertyEditor for Number (for example, Long, Short, Integer), initializing the form components is always an exception. Thus, a custom CustomPropertyEditor such as AgeEditor is implemented to initialize the <form:input path="age"/> to zero after form loading to avoid @Controller exceptions during data processing or service calls. Likewise, the DateEditor is implemented to handle a successful conversion of any request parameters that are needed to be java.util.Date type, such as the birthday property of EmployeeForm.

After the type conversion of all the request data, validators will come into the picture in the form of JSR 303/349 and Hibernate Validation annotations, in Spring's Validator framework. The JSR 303/349 Bean Validation offers some popular annotations that can be attached to each modelAttribute property for the purpose of maintaining data integrity. The following are the annotations applied to EmployeeForm:

Hibernate 5.x also has validation constraints that can be applied to form backing objects through its own set of annotations. EmployeeForm used @NotEmpty to apply a non-nullity constraint to emails. Also, it has an annotation, @Email, which has a built-in regular expression for correcting the email address format.

Most of the time, validation constraints are complex in nature and must be crafted through logic. Spring has an org.springframework.validation.Validator interface that can be implemented to apply form backing objects to custom integrity rules. The implementation also carries with it the use of utility class org.springframework.validation.ValidationUtils, which contains generic constraints such as rejectIfEmpty() or rejectIfEmptyOrWhitespace. All violations are monitored and registered by Spring in the BindingResult object. We enable BindingResult in our submitForm() to check if there are validation errors encountered, and this can be retrieved for display in some views.

The tandem of PropertyEditor and Validator will not work without the creation of the @InitBinder method of the controller. The general role of @InitBinder is to alter the normal course of parameter modelAttribute binding. It initializes the WebDataBinder object so that it can use addValidators() or setValidator() to apply integrity rules on the modelAttribute and registerCustomerEditor() methods to configure custom PropertyEditors.