Within the model of a Java web application, we can define validation rules using annotations from the
jakarta.validation.constraints package. This package provides a variety of annotations that are useful in common circumstances, and which can be applied to model fields.
We’ll use only a few of these annotations, but you can find a full list in the package documentation .
|Specifies minimum and/or maximum length for a string.|
|Specifies the minimum value of a numeric field.|
|Specifies the maximum value of a numeric field.|
|Specifies that a string field should conform to email formatting standards.|
|Specifies that a field may not be |
|Specifies that a string field contains at least one non-whitespace character.|
To apply the validation rules of the example on the previous page to the fields of a
User model class, we can use
@NotBlank @Size(min = 3, max = 12) private String username; @NotBlank @Size(min = 6) private String password;
Defining Validation Messages
Each of these annotations takes an optional
message parameter that allows you to define a user-friendly description to be used when validation fails.
@NotBlank(message = "Username is required") @Size(min = 3, max = 12, message = "Username must be between 3 and 12 characters long") private String username; @NotBlank(message = "Password is required") @Size(min = 6, message = "Sorry, but the given password is too short. Passwords must be at least 6 characters long.") private String password;
We will see how to ensure these messages are properly displayed in the next section on validating models.
Applying Validation Annotations - Video
Applying Validation Annotations - Text
To configure validation on the model-side, we begin by adding validation annotations to each field to which we want to apply constraints.
Event class, we add
@NotBlank to the
name field, and just
@Size to the
max parameters for
@Size specify the minimum and maximum number of allowed characters, respectively. Omitting either of these means that no min or max will be applied for the field. For our
description field, leaving off
min effectively makes this field optional.
Each of our annotations also receives a
message parameter, which provides a user-friendly message to display to the user if the particular validation rule fails. We will see how to display these in a view a bit later.
Next, we add a new field to store a contact email for each event. This is a
contactEmail. Validating email addresses by directly applying each of the rules that an email must satisfy is extremely difficult. Thankfully, there is an
After adding this new field to our constructor, and generating a getter and setter, our class is done for the moment.
The full list of Java validation annotations is in the
Before we can start up our application, we need to add a new column to the
events/index template to make
Now we can start up our application and test. Submitting an empty form at
/events/create still results in an event being created, which may not be what you were expecting.
Rather than a bug, this is expected behavior. Recall that validation involves both the model and controller, but we have not modified the controller in any way. Validation annotations simply define the validation rules that should be used to check data. The responsibility of checking the data before saving a new event lies with the controller.
In the next section, we’ll modify the controller to properly check for valid data.
Check Your Understanding
True or False: When using
@Size you must provide both
True or False: Adding validation annotations to a model ensures that bad data is not saved.