Validation Symfony : déclarer les règles avec des contraintes

La validation dans Symfony déclare sur l'entité, par des contraintes, ce qu'une donnée doit respecter : présence, format, bornes, unicité.

#[ORM\Entity(repositoryClass: InscriptionRepository::class)]
#[UniqueEntity(fields: ['soiree', 'email'], message: 'Vous êtes déjà inscrit à cette soirée.', errorPath: 'email')]
class Inscription
{
    #[ORM\Column(length: 180)]
    #[Assert\NotBlank(message: 'Indiquez votre adresse.')]
    #[Assert\Email(message: 'Indiquez une adresse valide.')]
    private ?string $email = null;

    #[ORM\Column]
    #[Assert\Range(notInRangeMessage: 'De {{ min }} à {{ max }} personnes par inscription.', min: 1, max: 6)]
    private int $personnes = 1;
}

Les règles s'écrivent une fois, là où vit la donnée : #[Assert\NotBlank], #[Assert\Length], #[Assert\Range] ou #[Assert\GreaterThan('now')] sur les propriétés, #[UniqueEntity] sur la classe, chacune avec son message. Un formulaire, #[MapRequestPayload] ou une commande les appliquent ensuite sans les répéter. Pour un simple paramètre d'URL, #[MapQueryParameter] valide déjà le type et les bornes par ses options de filtre. Le piège : #[UniqueEntity] sur deux champs rattache l'erreur au premier, soiree, que le formulaire n'affiche pas. Sans errorPath: 'email', le message tombe en tête du formulaire, loin du champ à corriger.

Les exercices font refuser dans l'URL un nombre de convives hors de 1 à 12, puis poser les contraintes et leurs messages sur les soirées de contes et leurs inscriptions, dont l'inscription unique par adresse et par soirée. Côté Laravel, un exercice remplace une closure par la règle array_keys, qui n'accepte dans un tableau que les clés prévues.