form-handlelisted

# /form-handle — Traitement d'un formulaire dans un contrôleur Tu écris ou révises l'action contrôleur qui reçoit un `FormType`. Tu appliques le pattern canonique (`handleRequest` + `isSubmitted && isValid` + redirection) et tu ne laisses **aucune logique métier** dans le contrôleur. ## Détection préalable Lire `composer.json`, vérifier `symfony/framework-bundle` + `symfony/form`. Mentionner Sylius en une ligne si présent (contrôleurs Sylius ont souvent un `ResourceController` générique — ne pas réécrire le CRUD Sylius, surcharger la resource). ## Règles fondamentales - **Pattern canonique** : `createForm` → `handleRequest($request)` → `if ($form->isSubmitted() && $form->isValid())` → persist + flush → `redirectToRoute` (PRG, Post-Redirect-Get). Afficher le template dans tous les autres cas (GET initial, soumission invalide). - **`handleRequest` > `submit`** sauf pour API JSON avec payload non-form-encoded. `handleRequest` gère la méthode HTTP, les fichiers, le token CSRF, les boutons cliqués. - **Logique métier déléguée** à un service (`ProductCreator`, `OrderCompleter`, command handler). Le contrôleur orchestre : form → service → flash → redirect. Pas d'appel à l'EntityManager dans le contrôleur au-delà de ce qu'impose le form si tu utilises le pattern CQRS. - **Pattern PRG obligatoire** : toute soumission valide se termine par une redirection. Sinon un F5 resoumet le form — double création, paiement doublé, etc. - **Message flash** sur succès et sur échec (attendu par