Compound
Warning: You are browsing the documentation for Symfony 6.3, which is no longer maintained.
Read the updated version of this page for Symfony 7.1 (the current stable version).
To the contrary to the other constraints, this constraint cannot be used on its own. Instead, it allows you to create your own set of reusable constraints, representing rules to use consistently across your application, by extending the constraint.
Applies to | class or property or method |
Class | Compound |
Validator | CompoundValidator |
Basic Usage
Suppose that you have different places where a user password must be validated, you can create your own named set or requirements to be reused consistently everywhere:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
// src/Validator/Constraints/PasswordRequirements.php
namespace App\Validator\Constraints;
use Symfony\Component\Validator\Constraints\Compound;
use Symfony\Component\Validator\Constraints as Assert;
#[\Attribute]
class PasswordRequirements extends Compound
{
protected function getConstraints(array $options): array
{
return [
new Assert\NotBlank(),
new Assert\Type('string'),
new Assert\Length(['min' => 12]),
new Assert\NotCompromisedPassword(),
new Assert\PasswordStrength(['minScore' => 4]),
];
}
}
Add #[\Attribute]
to the constraint class if you want to
use it as an attribute in other classes. If the constraint has
configuration options, define them as public properties on the constraint class.
You can now use it anywhere you need it:
1 2 3 4 5 6 7 8 9 10
// src/Entity/User.php
namespace App\Entity\User;
use App\Validator\Constraints as Assert;
class User
{
#[Assert\PasswordRequirements]
public string $plainPassword;
}
Options
groups
type: array
| string
default: null
It defines the validation group or groups of this constraint. Read more about validation groups.
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.