Jour 6 - Créer des formulaires Symfony propres pour publier les articles

Un formulaire mal pensé ruine l’expérience admin. On veut un formulaire simple à remplir, difficile à casser, facile à maintenir.

Aujourd’hui on travaille le couple FormType + validation Symfony.

Objectif d’apprentissage

Mettre en place un formulaire maintenable pour créer/éditer des articles, avec des validations utiles et une UX claire.

Ce que tu vas pratiquer aujourd’hui

• Créer un FormType propre et lisible.
• Brancher les validations côté entity.
• Afficher les erreurs proprement en Twig.
• Gérer les messages succès/erreur en flash messages.

1. Créer un FormType dédié

Le FormType évite d’écrire le HTML à la main et sécurise le mapping des champs.

On garde un nommage clair et des placeholders utiles.

final class BlogPostType extends AbstractType
{
    public function buildForm(FormBuilderInterface $builder, array $options): void
    {
        $builder
            ->add('title')
            ->add('slug')
            ->add('excerpt', TextareaType::class)
            ->add('content', TextareaType::class)
            ->add('status', ChoiceType::class, [
                'choices' => ['Brouillon' => 'draft', 'Publié' => 'published'],
            ]);
    }
}

2. Gérer la soumission dans le controller

Le contrôleur doit rester simple: créer le formulaire, traiter la requête, persister si valide.

Ajoute un message clair pour confirmer la publication.

$form = $this->createForm(BlogPostType::class, $post);
$form->handleRequest($request);

if ($form->isSubmitted() && $form->isValid()) {
    $entityManager->persist($post);
    $entityManager->flush();
    $this->addFlash('success', 'Article enregistré.');

    return $this->redirectToRoute('admin_blog_post_index');
}

3. Rendre le formulaire en Twig

Utilise les helpers Twig de formulaire pour un rendu cohérent et accessible.

N’oublie pas d’afficher explicitement les erreurs globales.

{{ form_start(form) }}
    {{ form_errors(form) }}
    {{ form_row(form.title) }}
    {{ form_row(form.slug) }}
    {{ form_row(form.excerpt) }}
    {{ form_row(form.content) }}
    <button class="resume-btn resume-btn-primary">Enregistrer</button>
{{ form_end(form) }}

Checklist de fin de session

• FormType opérationnel.
• Validation active.
• Erreurs visibles côté UI.
• Message succès après soumission valide.

Erreurs fréquentes à éviter

• Sauter la vérification finale parce que “ça marche chez moi”.
• Mélanger trop de logique dans le controller au lieu de garder un flux clair.
• Oublier la cohérence entre la donnée, le template Twig et le comportement en production.

Pourquoi cette étape compte en conditions réelles

Dans un vrai projet client, chaque étape technique doit rester compréhensible par l’équipe, duplicable sur un autre environnement et fiable dans le temps. Ici, l’objectif est de transformer la théorie en un flux de travail concret, avec des décisions simples que tu peux défendre en revue de code.

Si tu appliques sérieusement les points du jour (créer un formtype propre et lisible.), tu réduis la dette technique dès le départ et tu facilites la suite: SEO, publication, maintenance et déploiement. C’est exactement la différence entre un blog “démo” et un blog exploitable en production.

Mini plan de révision

• Reprends ce point et explique-le à voix haute comme si tu faisais un code review : Créer un FormType propre et lisible.
• Reprends ce point et explique-le à voix haute comme si tu faisais un code review : Brancher les validations côté entity.
• Reprends ce point et explique-le à voix haute comme si tu faisais un code review : Afficher les erreurs proprement en Twig.

Exercice rapide

Rends le champ téléphone optionnel dans un formulaire de contact et valide le format uniquement si rempli.

Et demain ?

Demain, on passe à EasyAdmin pour publier les articles plus vite avec un back-office propre.