Skip to content

Valid

Edit this page

This constraint is used to enable validation on objects that are embedded as properties on an object being validated. This allows you to validate an object and all sub-objects associated with it.

Applies to property or method
Class Valid

Tip

By default, the error_bubbling option is enabled for the collection Field Type, which passes the errors to the parent form. If you want to attach the errors to the locations where they actually occur you have to set error_bubbling to false.

Basic Usage

In the following example, create two classes Author and Address that both have constraints on their properties. Furthermore, Author stores an Address instance in the $address property:

1
2
3
4
5
6
7
8
9
// src/Entity/Address.php
namespace App\Entity;

class Address
{
    protected string $street;

    protected string $zipCode;
}
1
2
3
4
5
6
7
8
9
10
11
// src/Entity/Author.php
namespace App\Entity;

class Author
{
    protected string $firstName;

    protected string $lastName;

    protected Address $address;
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
// src/Entity/Address.php
namespace App\Entity;

use Symfony\Component\Validator\Constraints as Assert;

class Address
{
    #[Assert\NotBlank]
    protected string $street;

    #[Assert\NotBlank]
    #[Assert\Length(max: 5)]
    protected string $zipCode;
}

// src/Entity/Author.php
namespace App\Entity;

use Symfony\Component\Validator\Constraints as Assert;

class Author
{
    #[Assert\NotBlank]
    #[Assert\Length(min: 4)]
    protected string $firstName;

    #[Assert\NotBlank]
    protected string $lastName;

    protected Address $address;
}

With this mapping, it is possible to successfully validate an author with an invalid address. To prevent that, add the Valid constraint to the $address property.

1
2
3
4
5
6
7
8
9
10
// src/Entity/Author.php
namespace App\Entity;

use Symfony\Component\Validator\Constraints as Assert;

class Author
{
    #[Assert\Valid]
    protected Address $address;
}

If you validate an author with an invalid address now, you can see that the validation of the Address fields failed.

1
2
App\Entity\Author.address.zipCode:
    This value is too long. It should have 5 characters or less.

Tip

If you also want to validate that the address property is an instance of the App\Entity\Address class, add the Type constraint.

Options

groups

type: array | string default: null

It defines the validation group or groups of this constraint. Read more about validation groups.

Note

Unlike other constraints, the Valid constraint does not use the Default group. This means that it will always be applied by default, even if you specify a group when calling the validator. If you want to restrict the constraint to a subset of groups, you have to define the groups option.

payload

type: mixed default: null

This option can be used to attach arbitrary domain-specific data to a constraint. The configured payload is not used by the Validator component, but its processing is completely up to you.

For example, you may want to use several error levels to present failed constraints differently in the front-end depending on the severity of the error.

restrictGroups

type: boolean default: true

Consider the following class:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// src/Entity/Address.php
namespace App\Entity;

use Symfony\Component\Validator\Constraints as Assert;

class Address
{
    #[Assert\NotBlank]
    public string $street;

    #[Assert\NotBlank(groups: ['shipping'])]
    public string $phoneNumber;

    #[Assert\NotBlank(groups: ['billing'])]
    public string $email;
}

The same class is used for the two addresses of an order. The street is always required. The phone number is only required for the shipping address, to coordinate the delivery. The email is only required for the billing address, because the invoice is sent by email:

1
2
3
4
5
6
7
8
9
10
11
12
13
// src/Entity/Order.php
namespace App\Entity;

use Symfony\Component\Validator\Constraints as Assert;

class Order
{
    #[Assert\Valid(groups: ['billing'])]
    public Address $billingAddress;

    #[Assert\Valid(groups: ['shipping'])]
    public Address $shippingAddress;
}

During the checkout, the application validates the Default group and the group named after each step (billing or shipping). When validating the billing step (the Default and billing groups), the $billingAddress is validated only against billing: the email is checked, but the NotBlank constraint of $street is silently skipped, even though you asked for the Default group too.

This happens because the groups option defines the full list of groups used to validate the nested object, and the Default group is not added in this example. Set restrictGroups to false to disable that behavior and validate each nested object against the same groups as its parent object:

1
2
3
4
5
#[Assert\Valid(groups: ['billing'], restrictGroups: false)]
public Address $billingAddress;

#[Assert\Valid(groups: ['shipping'], restrictGroups: false)]
public Address $shippingAddress;

Even when setting the restrictGroups option to false, the groups option still decides when the cascade validation happens: when validating the billing step, the $shippingAddress is never validated, and vice versa.

8.2

The restrictGroups option was introduced in Symfony 8.2.

traverse

type: boolean default: true

If this constraint is applied to a \Traversable, then all containing values will be validated if this option is set to true. This option is ignored on arrays: Arrays are traversed in either case. Keys are not validated.

This work, including the code samples, is licensed under a Creative Commons BY-SA 3.0 license.
TOC
    Version