FORM VALIDATION
Before addressing validation, let’s see how we can externalize the labels of our forms to facilitate their internationalization.
OUTSOURCE LABELS
The more observant will have realized that in the forms we used labels wired directly into the code. As a first step to outsource labels, we need to make configuration-level changes. Let’s open the WebApplicationContextConfig.java file and modify it as follows. As you see from the figure below, the Bean does nothing more than configure the message source. The setBasename property sets a text file to be the source.
Now we need to create a properties file having exactly the same name i.e. messages in src/main/resources. I bring back a small excerpt. As you see the following convention is followed: form name followed by the word form then control name and finally label.
In the input form we need to add the following spring:message tag. Buttons can also be labeled with this technique.
INTERNATIONALIZATION TECHNIQUES
Now we will take it a step further and from simple outsourcing we will see how it is possible to create multilingual applications. In this example we will limit ourselves to the English language only. In the src/main/resources folder we create a new messages_en.properties file that will contain all the labels translated into the English language.
It is very important that all elements stay on both properties files. Once the labels are in place, we need to edit the WebApplicationContextConfig.java configuration file. We first insert interceptors, which are elements that allow specific operations to be performed before or after a call. Specifically, it will open a page after translating the respective labels, selected by clicking on a button or link. The most important element is the specification of a “language” string. We will see that this string must be the same in the JSP page especially in the links that determine the language change. After adding the interceptor we need to tell Spring MVC what our default language is. Specifically, what language our page will open with. This Bean is called LocaleResolver.
Let’s go look at the links in our input JSP page. The parameters entered in the interceptor must be consistent with the links set at the jsp page level. As you see we used language as in the interceptor.
Since img is not present under the static folder we have to add a Handler in the configuration file as seen in the WebApplicationContextConfig.java class above. That method maps the /img/ path followed by anything else to the /static/images folder present under the static directory. Basically against the path /static/images corresponds the path /img/.
VALIDATION WITH BEAN VALIDATION
Bean validation is a validation system that relies on specific notations that are taken from Hibernate. Hibernate is an ORM and we will elaborate on it later. Theoretically, not having set up any controls, a user could enter anything into the form. The first step in updating the project is to go and edit our POM.XML file to work with Hibernate notations.
We then modify the WebApplicationContextConfig.java configuration file by introducing a new Bean that triggers Bean Validation. As you can see, we have made the settings of the origin of the displayed messages, and again these messages and language variants will have to be placed in the messages .properties and messages_en.properties files. The messageSource created in a previous Bean Is nothing more than the origin of our messages. The last modification returns the newly created validator.
Hibernate validation notations will need to be placed in the private fields of our Articoli domain class.
|
Annotation |
Usages |
|---|---|
| @NotNull | A field annotated with this should not be null |
| @NotEmpty | A field annotated with this should not be empty |
| @NotBlank | This field should not be null and not blank |
| @Min | Given Minimum value has to be satisfied |
| @Max | Given Maximum value has to be satisfied |
| @Size(min=x, max=y) | Field size should be less than or greater than the specified field size |
| Email can be validated with this | |
| @Pattern(regexp=”pattern”) | Given RegEx Pattern has to be satisfied. |
|
@Digits(integer=x, fraction=y) |
Validates that the field value consists only of digits, with the specified number of integer and fractional digits allowed. |
|
@Posititve |
The field value must be a positive number (greater than zero). |
| @NegativeOrZero |
The field value must be either zero or a negative number. |
|
@Future |
The field value must represent a date and time in the future (after the current instant). |
|
@FutureOrPresent |
The field value must represent a date and time either in the present or the future. |
|
@PastOrPresent |
The field value must represent a date and time either in the past or the present. |
|
@Range(min=x, max=y) |
The field value must be within the specified range (inclusive of both min and max values). |
|
@URL |
Validates the field as a valid URL according to a predefined regex pattern. |
|
@CreditCardNumber |
Validates the field as a valid credit card number according to the Luhn algorithm. |
This is the domain class Articoli.
The messages follow this convention: Name of the notation, the class in which it is applied, the name of the private field, and finally validation. These messages should be present in the two properties files along with their error messages. Having done this you edit the article entry and update pages, I show you an excerpt of the page. We are basically setting the error variable with the contents of a special form:errors tag that takes all the fields. If the variable is not empty the error message(s) is shown.
Let’s finally look at the changes to be made to the controller, let’s analyze insertion, similar speech applies to update. With the GET method we value the category and vat combos and return an empty form ready to be filled in. In the POST, note that the mapping is always the same, we insert the fundamental notation @Valid which is the actual originator of the validation, in case the BindingResult has an error result.hasError() returns true (presence of validation errors) then the error correction form is presented again. If not, insertion is carried out.
DOWNLOAD ARTICLE CODE
The AlphaShopV4.zipper project is for the SQL Server DBMS while AlphaShopV5.zipper is for MySQL.
Leave A Comment