Valid
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.