Jour 4 - Construire le routing et les controllers du blog

Le routing est la colonne vertébrale de ton blog. Des routes simples et stables facilitent tout: SEO, partage, maintenance.

On va créer deux points d’entrée: la liste des articles et la page détail.

Objectif d’apprentissage

Mettre en place des routes claires et un flux controller → repository → template sans logique métier parasite.

Ce que tu vas pratiquer aujourd’hui

• Déclarer des routes propres et explicites.
• Injecter le repository dans le controller.
• Renvoyer uniquement les articles publiés.
• Préparer des réponses HTTP cohérentes (200 / 404).

1. Créer la route de listing

La route /blog doit afficher un listing simple, propre et trié.

Le controller reste court: il orchestre seulement.

#[Route('/blog', name: 'app_blog_index', methods: ['GET'])]
public function index(BlogPostRepository $blogPostRepository): Response
{
    return $this->render('blog/index.html.twig', [
        'posts' => $blogPostRepository->findPublished(12),
    ]);
}

2. Créer la route de détail

La route par slug doit retourner une 404 propre si l’article n’existe pas.

On évite les redirections bancales et les erreurs silencieuses.

#[Route('/blog/{slug}', name: 'app_blog_show', methods: ['GET'])]
public function show(string $slug, BlogPostRepository $blogPostRepository): Response
{
    $post = $blogPostRepository->findPublishedBySlug($slug);
    if (!$post) {
        throw $this->createNotFoundException('Article introuvable.');
    }

    return $this->render('blog/show.html.twig', ['post' => $post]);
}

3. Valider les routes disponibles

Toujours vérifier les routes générées pour éviter les collisions de noms ou de chemins.

Ce check prend 5 secondes et évite beaucoup d’erreurs.

php bin/console debug:router | grep blog

Checklist de fin de session

• /blog retourne une liste.
• /blog/{slug} retourne l’article attendu.
• 404 propre si le slug n’existe pas.
• Aucune logique SQL dans le controller.

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 (déclarer des routes propres et explicites.), 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 : Déclarer des routes propres et explicites.
• Reprends ce point et explique-le à voix haute comme si tu faisais un code review : Injecter le repository dans le controller.
• Reprends ce point et explique-le à voix haute comme si tu faisais un code review : Renvoyer uniquement les articles publiés.

Exercice rapide

Ajoute un paramètre ?preview=1 côté admin pour afficher un brouillon sans le publier.

Et demain ?

Demain, on travaille le front Twig: layout, cartes d’articles et page détail lisible.