In this video we are going to look into validating the submitted form data before it can be saved off to the database.

We can use validation to ensure that the data received from a user's form submission is within the allowable guidelines determined in our code. This is to say that we could set a text field to be no fewer than 20 characters, or a datetime field should be in the future, or that a checkbox must be checked... and so on.

Symfony comes preconfigured with a large number of Validation Constraints, and I'd advise keeping this handy reference close to hand. Some you will use more than others, but having so many pre-defined options is really a huge time saver.

In previous videos we have been using the following code inside our controller actions:

if ($form->isSubmitted() && $form->isValid()) {

    // do something with the form data here


Which has been working just fine as without any validation constraints on the underlying data, whatever is submitted is considered to be valid.

We want to change that now to stop situations where bad or invalid data might find its way into our database.

HTML 5 Validation

If we are using Twig - as we are in this series - then when we render out a Symfony form from our controller action, then depending on the field types you use, you may get some HTML 5 inputs / form fields in your form.

An example of this would be the email field. Inside our database this would be a plain old string, but in our application we really need to ensure that it looks and feels like an email.

<input type="email" name="email">

As soon as a modern browser sees this, it will enforce some client side rules that ensure that by default, an @ symbol is present. The key point here is that these rules are only enforced on the client / users browser.

That is to say that if our form is configured as such, we could use an alternative client - Postman client, for example - to POST in our own form data and bypass any HTML 5 validation rules entirely.

If we haven't set up any entity validation rules then so long as what we submit is a string, you can very likely expect to find a non-conformant email address has found its way into your database.

You likely don't need to be told that this is exactly the sort of thing your boss / clients will get quite upset about, especially if it takes a while for this problem to be noticed.

The message here is quite simple - HTML 5 Validation is nice, but it is not an adequate way to protect your data.

A better solution is to use Symfony's validation component in conjunction with the previously mentioned validation constraints, which is thankfully extremely easy to both use and configure.

Back End Validation With Symfony

As mentioned, client side validation is nice to have, but we can't rely on it in isolation.

Instead, we can use validation constraints on our data - in our case, our entities - to ensure individual fields meet specific business rules that we can define:


// src/AppBundle/Entity/Product.php

namespace AppBundle\Entity;

use Doctrine\ORM\Mapping as ORM;
use Symfony\Component\Validator\Constraints as Assert;

 * @ORM\Entity
 * @ORM\Table(name="products")
class Product
    // * snip *

     * @ORM\Column(type="string")
     * @Assert\Length(min="10", minMessage="this value was too short")
    protected $title;

     * @ORM\Column(type="string")
     * @Assert\Email()
    protected $email;

    // * snip *

The key lines here are the use statement at the very top of the class, and then the @Assert annotations on the individual class properties.

Depending on the constraint you use will depend on the specific options available for that particular constraint.

And amazingly, that's all we need to do.

Now, the next time we submit the form, as part of the $form->isValid() method, these assertions / validation constraints will be used to validate that the submitted data is within the allowable rules for this particular entity.

If any of the particular fields fails the validation logic then an error will be added to the form, which Symfony again will helpfully render for us when reloaded the form. If you have been using the Bootstrap 3 template then you can even expect a very well styled output with the offending field outlined in red, with the error message displayed nearby.

Validation, when used in conjunction with Symfony's form, is one of the quickest wins you will get from using Symfony in general. It really is amazingly powerful for very little extra effort on our part. If using annotations, the constraint logic is directly above the field it applies too. Honestly, if you are not using validation, then you are missing out on one of Symfony's best features.

Share This Episode

If you have found this video helpful, please consider sharing. I really appreciate it.

Episodes in this series

# Title Duration
1 Creating a Contact Form 12:07
2 Creating New Doctrine Entities Using Symfony's Form 08:34
3 Updating Existing Doctrine Entities 07:52
4 Validating Form Data with Symfony 3 11:58
5 Styling and Customising Using Form Fragments 08:33
6 Symfony Forms For Designers 12:12
7 Number, Integer, Or Custom Float? 12:06
8 Handling Money 04:41
9 Just Look At My Range! 07:40
10 Dates - Not Just A Delicious Fruit 07:24
11 Dealing With Dates and Times 11:17
12 Introduction to ChoiceType 04:33
13 A Little More Choice 07:04
14 Simple Multiple Choice With Arrays 04:38
15 Many To Many With The EntityType Form Field 07:16
16 Part 1 - An Easy Way To Handle 'Other' With Drop Downs 11:06
17 Part 2 - Embedded Forms, Validation and Bootstrap Styling 18:55
18 Part 3 - Custom JavaScript 29:13
19 Timestamps on Symfony Forms 08:20