It seems that the next sensible step is to add the handler for the form.
Even in our diagram, this seems to be the next logical step.
So we need one page to display the form, but another one that will handle this post request and do
something with the input that is being sent to us.
And I think that this should be also our next step.
So let's go ahead and create a form handler.
So we need the root file for this contact post route.
Let's create it constant post PHP.
And inside it we can handle the form submission.
So what do we need to do here.
First we would have to handle the CSRF token.
But I just want to do it later.
The next thing is to get the data from the super global called post.
This will contain all the data sent through the form.
So let's get our data.
We need the name.
This is inside post name.
Or if this would be null, we just default to an empty string.
Next up we need the email.
Again we are taking this from the post super global or defaulting to an empty string.
And finally the message.
We do it the same way.
Okay, now we have the data.
It's time to validate it, see if it is empty.
And we will only have some special cases for email.
Or maybe we can also check some minimum length of the name or message.
Let's think about it later.
Next up, let's check if any of those values is empty.
For that, we're gonna just use a simple if statement and call the empty function.
So if either the name is empty or the email is empty or the message is empty, we just return the same
response code and the same message for the list of possible codes that we can return.
Let's check that in the MTN web docs.
I think that this here is a client error, and typically when the input is incorrect, I think that
this 400 is the most commonly returned status code.
So let's use this one.
So the code is returned using HTTP response code.
This is 400.
In our case we can additionally output a message saying all fields are required.
And finally, we should stop the request at this point using exit.
Now this looks a little bit like what we have inside the router.
This not found function.
That's why I think we can create another one here that will be called bad request.
This is also void.
And it will do those three things.
So we move it because this is something reusable.
So now let's jump back to the contact post handler.
And here let's just call bad request.
This will just return this response and just stop the execution.
So we don't really have to worry about stopping the script.
And then we should be verifying the email.
So if the email is not empty we also need to make sure that it is correct.
So there is a way for that.
And we can use the filter var function passing the email to it.
And the second argument is filter validate email.
So this filter var function can be used for different validations.
You can check emails IP addresses and a lot of other things.
So if I press control space again you can see quite a lot of different examples.
So in this case we actually need to verify the email.
So if the email would not be correct this would return false.
Which means again I can call Badrequest.
So you might have noticed that I tried to provide some default values for the ones that weren't provided
so that we can quickly and easily check if they are empty as they shouldn't be, and that we also don't
use nested if statements.
And instead, as soon as we realize that something went wrong, not according to our expectations,
we stopped the execution, which can be described as defensive programming.
And I think that this improves the security but also the readability of such programs.
So at this point, after this line, we should be pretty sure that the input is fine.
That's why I can vardump the email, the name and message and stop, because at this point, there is
nothing else we can do with this input other than inserting it to our database, which is a topic of
the next video, so I think we can try this out at this point.
So if I send an empty form, you can see that there is an all fields are required message.
So maybe I'm gonna zoom in so that it's visible.
Now if all fields are provided well we've got this check that will verify the email so that now there
is a success message.
But for just a second, let me modify the contact template so that this field is not of type email.
Instead it is of type text.
So I would be able to send an invalid message.
And I think we are having.
Okay, so with Badrequest we are always returning the same message, which is not ideal.
That means we need to provide an argument here.
The message which can default to just part request.
And instead we're going to echo the message.
Now let me go back to the route handler.
Okay.
This first call should return this text.
All fields are required.
And this one will say email field is invalid.
Now let's try again with an invalid email.
And we see that email field.
Field is invalid.
All right that's it for now.
Next up we are going to be starting working with a database.
So we'll be inserting this data to a database.