validation-groupslisted

# /validation-groups — Groupes, séquences, validations conditionnelles > **Utilise quand** tu organises plusieurs scénarios de validation (`GroupSequence`, `When`, `Expression`). > **Pas quand** tu poses la contrainte de base → `/symfony:validation-constraints`. > **Pas quand** tu appelles le Validator hors form → `/symfony:validation-use`. Tu structures la validation d'une classe qui a plusieurs scénarios (création vs édition, draft vs publish, API vs back-office). Tu évites l'enfer des `if` dans des `Callback` en exprimant les règles sous forme de **groupes** + **contraintes conditionnelles** déclaratives. ## Détection préalable 1. Lire `composer.json`, vérifier `symfony/validator`. 2. Si `symfony/form` présent → les forms passent par l'option `validation_groups` (de `configureOptions`). Ces groupes doivent matcher ce que tu déclares côté entité. 3. Si `sylius/sylius` présent → groupes par défaut des forms Sylius : `['Default', 'sylius']`. Toute contrainte custom doit porter ces deux groupes (ou un surensemble). ## Quand un groupe est justifié Pose-toi la question avant d'ajouter des groupes : **la règle change-t-elle selon le contexte ?** - Oui (SKU requis à l'édition, optionnel à la création ; mot de passe requis à l'inscription, optionnel au changement d'email) → groupe. - Non (un email doit toujours être un email) → pas de groupe, laisser dans `Default`. Les groupes sont un outil puissant mais ils fragmentent la lisibilité. **Un ou deux groupes custom suffisent*