TP n°4 - Programmation contrôleur Web Symfony
Code applicatif PHP déclenché en réponse aux requêtes HTTP

Lancez le serveur Web, comme déjà vu à la séance précédente :

cd $HOME/CSC4101/tp-02/todo-app/
symfony server:start

Dans la suite de la séance, vous allez tester l’exécution de l’application « fil rouge » ToDo dans un contexte Web. L’application s’exécutera en « boucle », réagissant en réponse aux requêtes transmises à travers le serveur HTTP de PHP. Si vous mettez à jour le code, ces mises à jour seront prises en compte sans avoir à relancer le serveur HTTP. Gardez le terminal ouvert avec le serveur lancé dedans, pour pouvoir consulter les logs sur la sortie dans le terminal au fur et à mesure de la mise-au-point.

1. Consultez la page affichée pour http://localhost:8000/ dans le navigateur.

   Remarquez la « barre d’outils » située en bas de page.

2. Vérifiez ce qui se passe quand on place la souris au-dessus du code de réponse (404)

   Remarquez le Route name « n/a » affiché dans le « pop-up »

3. Cliquez sur cette case avec le code de retour. Une page s’affiche qui donne des détails sur le contexte d’exécution Symfony qui a donné lieu à la réponse HTTP en question/

   Examinez la page du « Profiler Symfony » qui s’affiche.

   Identifiez les informations de mise-au-point utiles, expliquant le contexte détaillé de la requête HTTP en question.

1. Naviguez sur l’URL http://localhost:8000/todo/

   Une page d’accueil sommaire de l’application s’affiche. Quel est le code de réponse de la réponse HTTP ?

   Vérifiez ce code aussi bien :

   • dans les traces du serveur sur sa sortie standard dans le terminal,
   • que dans la barre d’outils de Symfony affichée en bas de page.

2. Cliquez sur la case du code de retour « 200 » en bas à gauche de la barre d’outils Symfony

   Constatez les informations affichées dans la page « Request / Response » qui s’affiche, comme :

   le lien « TodoController::indexAction »

   nom du point d’entrée Symfony exécuté en réponse à la requête

   les « Request Headers »

   les en-têtes de la requête envoyés par le navigateur comme host, que vous connaissez

   le paramètre DATABASE_URL dans les « Server Parameters / Defined in .env »

   la variable de connexion à la base de données que vous connaissez aussi

   …

3. Cliquez sur le menu « Routing » à gauche

   Remarquez le nom de la « route » correspant à cette requête : home et la correspondance avec le chemin d’URL /todo/.

   L’application Symfony maintient une table de routage des chemins d’accès aux ressources, et des codes PHP gestionnaires.

   Ici, la requête est réussie (code de retour 200) car on est sur une route connue.

   Le code du contrôleur Symfony gérant cette route qui a été invoqué est dans la méthode App\Controller\TodoController::indexAction, que nous verrons plus loin dans le code PHP.

4. Essayez de naviguer cette fois sur l’URL http://localhost:8000/hello

   Examinez le code de retour et les informations de routage affichées. Est-ce cohérent ?

Dans la séance précedente, on avait vu que le code de l’application pouvait être exécuté au moyen des classes de son interface en mode « ligne de commande », gérant des sous-commandes app:... de symfony console, pour afficher des informations sur la sortie standard, par exemple.

Par exemple, la commande symfony console app:list-todos invoquait l’exécution de la méthode App\Command\ListTodosCommand::execute présente dans le fichier PHP src/Command/ListTodosCommand.php.

Ici, en environnement Web, le code de l’application est exécuté via l’invocation par le moteur du noyau Symfony en fonction de sa table de routage.

Examinez la table de routage Web de l’application ToDo :

symfony console debug:router

Ainsi, l’accès par le client HTTP à l’URL http://localhost:8000/todo/ entraîne le traitement de la requête HTTP GET correspondante sur la ressource /todo/ routée vers la route nommée home.

On a vu tout à l’heure que cette route, home est gérée par une méthode App\Controller\TodoController::indexAction.

On va voir que cette méthode est celle d’une classe Contrôleur Symfony (codée dans le fichier src/Controller/TodoController.php).

Vérifiez que les routes listées ci-dessus sont bien accessibles à partir d’un navigateur :

• Liste des tâches : http://localhost:8000/todo/list
• Affichage d’une tâche : http://localhost:8000/todo/1
• …

Comparez la sortie de la commande debug:route, testez les URL correspondantes et consultez le code du contrôleur Web.

Vous comprenez maintenant comment est structuré le code de la couche présentation pour HTTP d’une application Symfony.

Vous allez utiliser l’assistant générateur de code make:controller de Symfony, pour générer une classe Contrôleur, qui nous permettra de consulter les étiquettes de l’application Todo, sur le modèle de la classe TodoController.

Procédez aux étapes suivantes :

1. utilisez l’assistant make:controller pour générer le code d’une classe TagController :

   symfony console make:controller TagController
   

   created: src/Controller/TagController.php
   created: templates/tag/index.html.twig
   
   
    Success! 
   
   
   Next: Open your new controller class and add some pages!
   

2. allons-y, et ouvrons le fichier source généré src/Controller/TagController.php dans l’IDE. Rechargez le contenu affiché dans le panneau d’arborescence des fichiers : on a généré de nouveaux fichiers, mais l’IDE ne s’en est probablement pas rendu compte.

   Vous constatez que le code est plutôt concis. L’assistant a généré également un fichier de gabarit Twig templates/tag/index.html.twig, et celui-ci est utilisé pour générer le contenu d’une page Web.

   Vous étudierez prochainement les gabarits Twig, donc on ne va pas aller voir le détail de ce gabarit pour l’instant

3. consultez la table de routage de l’application :

   symfony console debug:router
   

   Elle contient maintenant la nouvelle route app_tag accessible sur /tag, ce qui est conforme à la déclaration des attributs de la méthode index() dans le code du contrôleur (#[Route('/tag', name: 'app_tag')]).

4. lancez le serveur Web :

   symfony server:start
   

   Testez l’URL http://127.0.0.1:8000/tag

   Vous obtenez sans surprise la page « Hello TagController! » spécifiée par le gabarit templates/tag/index.html.twig.

5. Modifiez le code de la méthode index() pour ajouter un appel à dump() :

   #[Route('/tag', name: 'app_tag')]
   public function index(): Response
   {
       dump("hello world");
   
       return $this->render('tag/index.html.twig', [
           'controller_name' => 'TagController',
       ]);
   }
   

6. sans avoir besoin de relancer le serveur Web, rechargez juste la page /tag affichée dans le navigateur.

   Vous devez voir apparaître dans la barre d’outils Symfony en bas de page, une icône « cible » qui donne accès à l’affichage des dumps (il suffit de passer la souris dessus pour voir les messages en pop-ups).

Le code généré est maintenant dispobible pour que vous spécifiez les traîtements à effectuer pour afficher une liste d’étiquettes.

Nous pouvons maintenant ajouter une méthode destinée à charger et afficher toutes les étiquettes.

1. Ajoutez la méthode suivante :

   use App\Repository\TagRepository;
   
   // ...
   
       /**
        * Lists all tags entities.
        */
       #[Route('/tag/list', name: 'tag_list', methods: ['GET'])]
       public function listAction(TagRepository $tagRepository)
       {
           $htmlpage = '<!DOCTYPE html>
   <html>
       <head>
           <meta charset="UTF-8">
           <title>todos list!</title>
       </head>
       <body>
           <h1>tags list</h1>
           <p>Here are all your tags:</p>
           <ul>';
   
           $tags = $tagRepository->findAll();
           foreach($tags as $tag) {
               $htmlpage .= '<li>'. $tag->getName() .'</li>';
           }
           $htmlpage .= '</ul>';
   
           $htmlpage .= '</body></html>';
   
           return new Response(
               $htmlpage,
               Response::HTTP_OK,
               array('content-type' => 'text/html')
               );
       }
   

   La génération du HTML est inspirée de ce qui est fait dans TodoController::listAction() (on verra plus tard comment faire mieux avec des gabarits).

   Quand à la connexion avec la base de données, on diffère un peu du code de TodoController : on utilise ici le mécanisme de « cablage » automatique des contrôleurs avec les repositories de Doctrine (présenté dans le deuxième exemple de la documentation Fetching Objects from the Database).

   Testez que cela affiche bien les tâches présentes dans la base de données.

2. Cliquez sur l’icône représentant un « cylindre » à 3 couches en bas de page dans la barre d’outils du développeur Symfony.

   Vous aboutissez à la page « Doctrine » des outils de mise au point, qui permet de voir la requête SELECT qui a été générée par Doctrine lors de l’appel à findAll().

Voilà pour la création d’un contrôleur sur l’application Todo. Vous pouvez maintenant passer à l’ajout de contrôleurs dans votre projet.