Contactez-nous

Etape 2 : Créer le contrôleur pour gérer la logique (données en dur pour l'instant)

Apprenez à créer un contrôleur Symfony avec `make:controller`, à implémenter la logique métier pour lister et afficher des tâches en utilisant des données codées en dur, et à gérer les cas d'erreur comme la tâche non trouvée.

Génération du squelette du contrôleur avec Symfony CLI

Maintenant que nos routes sont définies, l'étape suivante consiste à créer le contrôleur qui contiendra la logique métier associée à ces routes. Un contrôleur dans Symfony est une classe PHP dont les méthodes (appelées actions) sont responsables de la gestion des requêtes HTTP et de la préparation de la réponse à renvoyer au client.

Symfony fournit un ensemble d'outils pratiques via sa console, notamment les commandes `make:*`, qui permettent de générer rapidement des squelettes de code. Pour créer notre contrôleur dédié aux tâches, nous allons utiliser la commande `make:controller`. Ouvrez votre terminal à la racine de votre projet et exécutez :

php bin/console make:controller TaskController

Symfony vous posera peut-être quelques questions, mais vous pouvez généralement accepter les valeurs par défaut. Cette commande va créer un nouveau fichier TaskController.php dans le répertoire src/Controller/. Ce fichier contiendra une classe TaskController héritant de AbstractController (qui fournit de nombreux raccourcis utiles) et une méthode d'exemple, généralement nommée index(), déjà associée à une route basique. Nous allons modifier cette classe pour y intégrer nos propres méthodes correspondant aux routes app_task_list et app_task_show.

Implémentation des données en dur et de la logique de la liste des tâches

Pour cette phase initiale de notre projet, nous n'utiliserons pas de base de données. A la place, nous allons simuler nos données de tâches directement dans le contrôleur sous forme d'un tableau PHP. Ajoutez une propriété privée à votre TaskController pour stocker ces tâches :

namespace App\Controller;

use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Attribute\Route;
// N'oubliez pas d'importer NotFoundHttpException si vous l'utilisez plus tard
// use Symfony\Component\HttpKernel\Exception\NotFoundHttpException;

class TaskController extends AbstractController
{
    private array $tasks = [
        ['id' => 1, 'title' => 'Acheter du pain', 'description' => 'Ne pas oublier la baguette tradition.', 'completed' => false],
        ['id' => 2, 'title' => 'Répondre aux emails', 'description' => 'Traiter les emails professionnels urgents.', 'completed' => true],
        ['id' => 3, 'title' => 'Apprendre Symfony', 'description' => 'Suivre le cours CertiQuizz avec attention.', 'completed' => false],
        // Ajoutez d'autres tâches si vous le souhaitez
    ];

    // ... la suite des méthodes
}

Ensuite, nous allons implémenter la méthode qui gère la route app_task_list. Cette méthode, que nous pourrions nommer index() ou listTasks(), aura pour rôle de passer notre tableau $tasks à un template Twig (que nous créerons à l'étape 3) pour affichage. La méthode render(), héritée de AbstractController, est parfaite pour cela.

// Dans la classe TaskController

    #[Route('/taches', name: 'app_task_list', methods: ['GET'])]
    public function index(): Response // Ou listTasks(), adaptez le nom si besoin
    {
        // Nous passons le tableau de tâches au template 'task/index.html.twig'
        // La clé 'tasks' dans le tableau associatif sera le nom de la variable
        // accessible dans le template Twig.
        return $this->render('task/index.html.twig', [
            'tasks' => $this->tasks,
        ]);
    }

    // ... la suite
}

Le premier argument de $this->render() est le chemin vers le fichier template Twig (relatif au répertoire templates/). Le second argument est un tableau associatif où chaque clé devient une variable disponible dans ce template. Ici, notre template index.html.twig aura accès à une variable nommée tasks contenant notre tableau de tâches.

Implémentation de la logique pour afficher le détail d'une tâche

La seconde fonctionnalité est d'afficher le détail d'une tâche spécifique. La méthode associée à la route app_task_show, que nous pourrions nommer show() ou showTask(), recevra l'$id de la tâche en paramètre, grâce à la configuration de notre route.

La logique de cette méthode consistera à rechercher dans notre tableau $this->tasks la tâche dont l'identifiant correspond à l'$id fourni. Si la tâche est trouvée, nous la passerons à un template Twig dédié (par exemple, task/show.html.twig). Si aucune tâche ne correspond à cet $id, il est crucial de gérer ce cas d'erreur. Une bonne pratique est de lever une exception NotFoundHttpException, que Symfony interceptera automatiquement pour afficher une page d'erreur 404 (Not Found).

// Dans la classe TaskController (suite)

// N'oubliez pas l'import si ce n'est pas déjà fait :
use Symfony\Component\HttpKernel\Exception\NotFoundHttpException;

    #[Route('/tache/{id}', name: 'app_task_show', methods: ['GET'], requirements: ['id' => '\d+'])]
    public function show(int $id): Response // Ou showTask(), adaptez le nom
    {
        $foundTask = null;
        foreach ($this->tasks as $task) {
            if ($task['id'] === $id) {
                $foundTask = $task;
                break; // Tâche trouvée, on arrête la boucle
            }
        }

        // Si la tâche n'a pas été trouvée dans notre tableau
        if (!$foundTask) {
            // Lève une exception 404, Symfony affichera une page d'erreur standard
            throw $this->createNotFoundException('La tâche avec l\'identifiant ' . $id . ' n\'existe pas.');
        }

        // Si la tâche est trouvée, on la passe au template 'task/show.html.twig'
        return $this->render('task/show.html.twig', [
            'task' => $foundTask, // La variable 'task' sera accessible dans le template
        ]);
    }
}

La méthode $this->createNotFoundException() est un raccourci pratique fourni par AbstractController pour instancier une NotFoundHttpException. L'utilisation du typage int $id pour le paramètre de la méthode show assure, en conjonction avec la contrainte requirements: ['id' => '\d+'] de la route, que Symfony tentera de convertir le paramètre de l'URL en entier avant d'appeler la méthode. Si la conversion échoue (par exemple, si l'URL est /tache/abc), la route ne correspondra pas, et Symfony affichera une erreur 404 avant même d'atteindre notre logique de recherche.

Avec ces deux méthodes implémentées, notre contrôleur est maintenant capable de gérer la logique de base pour lister les tâches et afficher le détail d'une tâche spécifique, en utilisant pour l'instant nos données codées en dur.