Le rôle central du contrôleur dans Symfony

Une fois qu'une route a été définie et qu'elle correspond à une requête utilisateur, Symfony dirige cette requête vers le contrôleur associé. Le contrôleur est une classe PHP dont les méthodes, appelées actions, contiennent la logique nécessaire pour traiter la requête et générer une réponse.

Le contrôleur agit comme un chef d'orchestre pour une requête donnée. Ses responsabilités principales incluent :

• Accéder aux informations de la requête : Récupérer les paramètres de l'URL, les données d'un formulaire soumis, les en-têtes HTTP, etc.
• Interagir avec les services de l'application : Par exemple, communiquer avec la base de données via Doctrine (pour lire ou écrire des données), utiliser un service d'envoi d'emails, appeler une API externe, etc.
• Appliquer la logique métier : Effectuer des calculs, prendre des décisions basées sur les données, valider des entrées utilisateur.
• Préparer les données pour la vue : Rassembler et structurer toutes les informations qui devront être affichées à l'utilisateur.
• Retourner un objet Response : En fin de compte, chaque action de contrôleur doit retourner un objet Symfony\Component\HttpFoundation\Response. Cet objet encapsule la réponse HTTP qui sera renvoyée au navigateur (contenu HTML, JSON, redirection, etc.).

Dans notre quête pour créer une page web simple, le contrôleur sera initialement assez basique, mais il est crucial de comprendre son rôle pour construire des applications plus complexes.

Créer ou identifier votre contrôleur

Si vous suivez notre exemple de la page "A Propos" de l'étape précédente, nous avons déjà évoqué la création d'un contrôleur nommé StaticPageController. Si vous ne l'avez pas encore fait, vous pouvez le générer en utilisant la commande Symfony Console :

php bin/console make:controller StaticPageController

Cette commande crée un fichier src/Controller/StaticPageController.php avec une structure de base. Si vous avez déjà un contrôleur où vous souhaitez ajouter la logique de votre nouvelle page (par exemple, un MainController ou DefaultController), vous pouvez simplement y ajouter une nouvelle méthode.

Un contrôleur dans Symfony est une simple classe PHP qui hérite généralement de Symfony\Bundle\FrameworkBundle\Controller\AbstractController. Hériter de AbstractController est très pratique car cela vous donne accès à de nombreuses méthodes raccourcis utiles, comme render() pour afficher des templates Twig, redirectToRoute() pour les redirections, createForm() pour les formulaires, etc.

Implémenter la méthode d'action et retourner une réponse

Dans l'étape 1, nous avons défini une route /a-propos avec le nom app_about et nous l'avons associée (implicitement ou explicitement) à une méthode de notre contrôleur. Supposons que nous ayons nommé cette méthode about().

La tâche principale de cette méthode about() est de retourner un objet Symfony\Component\HttpFoundation\Response. Pour une page web simple qui affiche du HTML, la réponse contiendra ce code HTML.

";
        $htmlContent .= "
" . htmlspecialchars($pageTitle) . "
";
        $htmlContent .= "
" . htmlspecialchars($description) . "
";
        $htmlContent .= "
Site créé le: " . $creationDate->format('d/m/Y') . "
";
        $htmlContent .= "";

        return new Response($htmlContent);
    }
}

Dans cet exemple :

• Nous avons ajouté l'instruction use Symfony\Component\HttpFoundation\Response; pour pouvoir utiliser la classe Response sans son namespace complet.
• La méthode about() est décorée avec l'attribut #[Route] que nous avons défini précédemment.
• A l'intérieur de la méthode, nous définissons quelques variables ($pageTitle, $description, $creationDate). C'est une simulation très simplifiée de la préparation de données. Dans une vraie application, ces données pourraient provenir d'une base de données, d'un fichier de configuration, etc.
• Nous construisons une chaîne HTML $htmlContent. Notez l'utilisation de htmlspecialchars() pour les variables injectées dans le HTML. C'est une mesure de sécurité basique pour prévenir les attaques XSS (Cross-Site Scripting), même si Twig gérera cela automatiquement pour nous plus tard.
• Finalement, nous créons une nouvelle instance de Response en lui passant notre contenu HTML et nous la retournons.

Si vous accédez maintenant à http://localhost:8000/a-propos (assurez-vous que votre serveur Symfony est démarré avec symfony server:start), vous devriez voir le titre, la description et la date s'afficher dans votre navigateur.

Accéder aux informations de la requête (optionnel pour cette page simple)

Bien que notre page "A Propos" actuelle n'en ait pas besoin, il est fréquent qu'un contrôleur doive accéder à des informations provenant de la requête HTTP. Symfony facilite cela grâce à l'injection de dépendances et à l'objet Request.

Si votre action de contrôleur a besoin de l'objet Request, vous pouvez simplement l'ajouter comme argument à votre méthode, et Symfony l'injectera automatiquement :

use Symfony\Component\HttpFoundation\Request; // N'oubliez pas d'importer

// ...

    #[Route('/recherche', name: 'app_search', methods: ['GET'])]
    public function search(Request $request): Response
    {
        $searchTerm = $request->query->get('q', 'valeur_par_defaut'); // Accède à un paramètre GET ?q=
        $page = $request->query->getInt('page', 1); // Accède à ?page= et le convertit en entier

        // Si c'était une soumission de formulaire POST :
        // $name = $request->request->get('name');

        $htmlContent = "&tt;html>&tt;body>Recherche pour: " . htmlspecialchars($searchTerm) . " (Page: " . $page . ")&tt;/body>&tt;/html>";
        return new Response($htmlContent);
    }

L'objet $request possède des "bags" (des objets conteneurs) pour accéder aux différents types de données :

• $request->query: Pour les paramètres GET (ceux dans l'URL après le ?, par exemple ?q=symfony&page=2).
• $request->request: Pour les paramètres POST (souvent envoyés par des formulaires HTML avec la méthode POST).
• $request->attributes: Pour les paramètres de la route (par exemple, si votre route est /blog/{slug}, slug sera dans $request->attributes, mais il est plus courant de les typer directement en argument de la méthode du contrôleur).
• $request->cookies: Pour les cookies.
• $request->files: Pour les fichiers uploadés.
• $request->headers: Pour les en-têtes HTTP.
• $request->server: Pour les variables du serveur (équivalent à $_SERVER).

Pour les paramètres de route, comme {id} dans #[Route('/article/{id}', name: 'article_show')], Symfony est encore plus malin. Si vous typez l'argument de votre méthode avec le même nom que le paramètre de route, Symfony l'injectera automatiquement :

    #[Route('/article/{id}', name: 'article_show', methods: ['GET'], requirements: ['id' => '\d+'])]
    public function showArticle(int $id): Response
    {
        // $id contient directement la valeur du paramètre {id} de l'URL, convertie en entier.
        return new Response("Affichage de l'article avec l'ID: " . $id);
    }

C'est la manière la plus propre et la plus recommandée d'accéder aux paramètres de route.

Pour notre page "A Propos", nous n'avons pas besoin de manipuler l'objet Request directement car elle n'attend aucun paramètre dynamique de l'URL ou de formulaire. La logique reste simple, consistant à préparer quelques chaînes de caractères.

A ce stade, vous avez défini une route et implémenté la logique minimale dans un contrôleur pour retourner du HTML brut. La prochaine étape consistera à rendre cette page plus professionnelle et maintenable en utilisant le moteur de templates Twig pour séparer la présentation (HTML) de la logique (PHP).