The process of adding form validation in Spring is threefold.

First, we'll annotate the entity class' fields with JPA validation annotations,

which come from the javax.validation.constraints package.

Then, we'll capture validation in what's called

a BindingResult in the controller final.

If there are validation errors, we'll redirect back to the form and

display those validation errors.

Let's get started by adding those validation annotations and by redirecting

back to the form without adding the category when errors are encountered.

The first step I mentioned was adding validation annotations and

we'll do that in the entity classes.

Let's head to the category class.

So under the model package, I will open the category class.

Here, I'll demonstrate just a few of the annotations we can use.

Let's start with the name field.

Let's make a decision that the value has to be present and

that its length must be between, say, three and twelve characters.

You can change this, if you'd like.

To do this, we'll add the NotNull annotation,

which will ensure that it's not blank, as well as the Size annotation.

And here, we can specify a minimum and maximum value.

So I'll say min = 3 and max = 12.

Next, let's add validation annotations for the colorCode field.

So I'll do that right here.

This value should be a valid hexadecimal color code as used in CSS, so

let's mark it as NotNull, so we make sure it's provided, and to ensure

that the value is a valid hexadecimal value, let's use the Pattern annotation.

Now, I'm going to use a regular expression here on which we could have an entire

course.

Check the teacher's notes for more regular expression info, and just note for

our purposes here, that regular expressions can be used to

intelligently detect patterns in strings.

So, I will start with the regular expression element in the annotation here.

And as far as the pattern I'm checking for, I'll enclose that in quotes.

I'd like it to start with a hash sign cuz a hex code in CSS starts with a hash sign.

And have each subsequent character come from the character class of either zero

through nine, lowercase a through f, uppercase A through

F, and I'd like that to be repeated six times.

And it looks like my right bracket snuck in there, as well.

There was IntelliJ doing all the work for me.

Okay.

That's all I'd like to validate in this entity.

Next, we'll go to the category controller to trigger validation and

capture the results.

Here, we'll focus on the add category method, which is down a bit, there we go.

What I'd like to do here is first trigger validation according to the constraints we

just added to the category entity.

And it turns out, this is really simple.

We add a valid annotation to the category parameter.

So this category parameter, before, we add the Valid annotation.

And just like that, it will trigger validation,

according to the constraints that we put on the category class.

Next, we'll need a way to capture errors, and in Spring,

this is most easily accomplished by including a binding result parameter, so

I’ll add that after the category parameter, BindingResult,

and I’ll just call it, result.

Now what we need to do is actually take alternate action if errors are found,

such as redirecting back to the form.

To detect errors, we can use an if statement.

I'll do that before our categories save.

So we can say if the result has errors,

what we can do here is redirect back to the form.

And to do that, we'll return a redirect back to the you URI that's used

to render the form, remember, this is not the name of the Thymeleaf view, but rather

the URI that will need to be requested in order for the form to be rendered.

Okay.

We're ready to test this.

Let's reboot and try to add a category with invalid data.

So I’m going to stop my current instance of my app, and

then I can reboot that thing, and

we'll wait for the app to both compile and fully boot.

There we go, application started, I'll switch back to Chrome.

Let me first try to add a category without supplying any data whatsoever.

So I'll add a category, and there we are, right back at the form, it may look like

nothing happened, but I certainly clicked add and got right back to the form.

Let me add a two character category name, and a color.

Remember, we said that the category name had to be between three and

twelve characters in length.

So I'll say Sp, and then I'll choose Blue, and click Add.

And once again, we're right back at the form, and

finally, let's make sure that we can successfully add a category if we do,

indeed, provide valid data for all fields.

So, I will type Spring here.

I'll choose Blue, why not, and click Add.

Great, there it is.

Now we still have more work to do, but

you're well on your way to fully implemented form validation.

So we've taken the critical step of introducing server side validation

into the flow of our application data, but we left out another critical piece.

When our form was re-displayed, we offered no indication that there was an error.

This could certainly leave users confused as to what just happened.

So next, we'll add form validation messages that tell users

exactly what went wrong when something does go wrong.