TP n°7 - Implémentation d’un CRUD sur ToDo
Générateurs de formulaires CRUD avec Symfony

Vous allez dupliquer l’arborescence du projet PHP obtenu à la fin de la séance précédente, pour travailler sur une nouvelle version.

Vous pourrez ainsi faire évoluer le code, et revenir en arrière si besoin, en comparant l’état à la fin de la séance prédente, avec l’état courant.

1. Effectuez les opérations suivantes pour dupliquer le dossier :

   cd "$HOME/CSC4101"
   cp -r tp-05 tp-07
   cd tp-07
   cd todo-app
   

2. Ensuite, dans ce nouveau projet, on va réinitialiser les rouages du cadriciel Symfony avec Composer :

   cd "$HOME/CSC4101/tp-07/todo-app"
   rm -fr composer.lock symfony.lock var/cache/ vendor/ .project
   symfony composer install
   

   Confirmez la génération de fichiers pour Docker (on ne s’en servira pas tout de suite, mais pourquoi ne pas les avoir… le rôle de Docker ne sera pas évoqué en cours, mais vous pouvez en parler à vos encadrants de TP).

Il est donc préférable de réinitialiser le projet radicalement : à un état le plus « propre » possible. On fait ensuite réinstaller par Composer les bibliothèques du cadriciel Symfony (installées dans vendor/), et reconfigurer certains fichiers de configuration associés.

Vous allez travailler sur un nouveau projet dans le workspace dans l’IDE Eclipse, importé depuis ce nouveau répertoire de travail.

1. Pour les utilisateurs de l’IDE Eclipse, supprimez les anciennes infos du projet Eclipse :

   cd "$HOME/CSC4101/tp-07/todo-app"
   rm -fr .project .settings/
   

2. Importez dans votre IDE cette nouvelle version du projet Symfony Todo sur laquelle vous allez maintenant travailler.

   Dans Eclipse vous pouvez importer ce nouveau projet dans le même workspace que le précédent, mais avec un nom distinctif (par exemple « todo-tp-7 »).

   Si besoin, vous pourrez comparer le code des deux projets « todo-tp-7 » et « todo-tp-5 ». Mais pour l’instant, et pour éviter de vous mélanger, nous vous conseillons de fermer le projet de la séance précédente (menu Project / Close …).

Nous avons déjà vu dans une séance précédente les générateurs :

• d’entité (make:entity)
• de contrôleur « basique », avec son template Twig par défaut (make:controller)

Cette fois, nous allons utiliser l’assistant make:crud qui génère, pour une entité du modèle de l’application, un contrôleur, un jeu de formulaires, des templates et méthodes associées à chacune des opérations CRUD suivantes :

• création d’une nouvelle entité (Create/new)
• consultation (Read), déclinée en deux sous-ensembles :
  • d’une collection d’entités (index)
  • d’une entité (show)
• modification d’une entité (Update/edit)
• suppression d’une entité (Delete)

Nous allons travailler sur une nouvelle entité du modèle qu’on va ajouter à l’application ToDo : l’entité Paste (collage).

Elle est censée permettre de garder dans notre application Web une trace de copiés-collés (mémos, astuces, bouts de code, …).

Une paste sera identifiée par :

• un contenu textuel (content)
• une date de sauvegarde (created)
• un type de contenu (content_type), optionnel, permettant éventuellement d’en typer le format avec un type MIME.

Attention : on utilise le type text et non string car les bouts de texte qu’on souhaite sauvegarder sont potentiellement longs.

Procédez aux étapes suivantes :

1. Utilisez l’assistant générateur de code pour ajouter au modèle de données une nouvelle entité Doctrine :

   symfony console make:entity
   

   Class name of the entity to create or update (e.g. FierceElephant):
   > Paste
   
   created: src/Entity/Paste.php
   created: src/Repository/PasteRepository.php
   
   Entity generated! Now let's add some fields!
   You can always add more fields later manually or by re-running this command.
   
   New property name (press <return> to stop adding fields):
   > content
   
   Field type (enter ? to see all types) [string]:
   > text
   
   Can this field be null in the database (nullable) (yes/no) [no]:
   > 
   
   updated: src/Entity/Paste.php
   
   Add another property? Enter the property name (or press <return> to stop adding fields):
   > created
   
   Field type (enter ? to see all types) [string]:
   > datetime
   
   Can this field be null in the database (nullable) (yes/no) [no]:
   > 
   
   updated: src/Entity/Paste.php
   
   Add another property? Enter the property name (or press <return> to stop adding fields):
   > content_type
   
   Field type (enter ? to see all types) [string]:
   > 
   
   Field length [255]:
   > 
   
   Can this field be null in the database (nullable) (yes/no) [no]:
   > yes
   
   updated: src/Entity/Paste.php
   
   Add another property? Enter the property name (or press <return> to stop adding fields):
   > 
   
   
   
    Success! 
   
   
   Next: When you're ready, create a migration with symfony console make:migration
   
   

2. Rafraîchissez le projet dans votre IDE, et vérifiez ensuite le code généré dans src/Entity/.

Les migrations Doctrine sont des scripts qui permettent de gérer les changement du modèle de données à appliquer au SGBD. Nous ne les avons pas étudiés jusqu’ici, et ils concernent principalement la gestion des applications en production.

Jusqu’à présent, dans les séances de TP, à chaque évolution du modèle de données, on utilisait la séquence suivante pour aligner le contenu de la base de données avec le nouveau modèle de données décrit dans les classes Doctrine :

1. suppression de la base de données : symfony console doctrine:database:drop --force
2. recréation de la base de données : symfony console doctrine:database:create
3. recréation du schéma de la base de données : symfony console doctrine:schema:create
4. rechargement des données de tests : symfony console doctrine:fixtures:load -n

Cette séquence est appropriée en développement : on recrée la base de donnée en repartant de zéro, et on teste l’ajout de données via les Fixtures. Mais il n’est pas question d’en faire autant quand on a une base de données en production, si l’on souhaite redéployer une nouvelle version de l’application.

Dans ce cas, on devra disposer d’une procédure de migration de la base de données, qui fera la mise à jour dans la base de données de production, sans rien supprimer (espérons).

C’est justement ce que permet de faire le module Migrations de Symfony, dont il est question dans le message de fin affiché par make:entity : « Next: When you’re ready, create a migration with symfony console make:migration ».

Essayons maintenant :

1. Générez un script de migration correspondant à la dernière évolution du schéma de la base de données, avec la commande suivante :

   symfony console make:migration
   

   created: migrations/Version20240828105223.php
   
   
    Success! 
   
   
   Review the new migration then run it with symfony console doctrine:migrations:migrate
   See https://symfony.com/doc/current/bundles/DoctrineMigrationsBundle/index.html
   
   

2. Observez dans votre IDE le script PHP qui vient d’être généré (ici migrations/Version20240828105223.php).

   Vous remarquerez qu’il revient ici à appliquer un CREATE TABLE pour la nouvelle entité ajoutée.

3. On peut donc appliquer cette migration à notre base de données. Il suffit de suivre les indications données dans ce message : « Run the migration with symfony console doctrine:migrations:migrate ».

   Donc lancez la commande suivante, et validez l’application de la migration :

   symfony console doctrine:migrations:migrate
   

   WARNING! You are about to execute a migration in database "main" that could result in schema changes and data loss. Are you sure you wish to continue? (yes/no) [yes]:
   

4. Vous pouvez maintenant lancer l’application et re-tester. Elle devrait toujours fonctionner comme précédemment pour la consultation des tâches de la base de données.

Procédez aux étapes suivantes :

1. Ajoutez un nouveau contrôleur CRUD PasteController, pour la classe Paste :

   symfony console make:crud
   

   
   The class name of the entity to create CRUD (e.g. BravePuppy):
   > Paste
   
   Choose a name for your controller class (e.g. PasteController) [PasteController]:
   > 
   
   Do you want to generate PHPUnit tests? [Experimental] (yes/no) [no]:
   > 
   
   created: src/Controller/PasteController.php
   created: src/Form/PasteType.php
   created: templates/paste/_delete_form.html.twig
   created: templates/paste/_form.html.twig
   created: templates/paste/edit.html.twig
   created: templates/paste/index.html.twig
   created: templates/paste/new.html.twig
   created: templates/paste/show.html.twig
   
   
    Success! 
   
   
   Next: Check your new CRUD by going to /paste/
   

2. Rafraîchissez le contenu du projet dans votre IDE, et consultez les fichiers générés.

   Vous pouvez voir que l’assistant a non-seulement généré le code PHP de la classe du contrôleur, dans src/Controller, mais aussi tous les éléments associés, comme des gabarits Twig nécessaires.

   Le code des méthodes index() et show() générées dans PasteController devrait vous sembler familier, très similaire à celui que vous avez ajouté dans une séquence précédente dans TaskController.

   On va voir le reste des méthodes ci-dessous.

Testez maintenant l’application qui permet maintenant une soumission de données :

1. Consultez la liste des nouvelles routes, avec symfony console debug:router
2. Lancez l’application en mode Web comme d’habitude

3. Testez l’application dans le navigateur derrière les chemins des pastes : http://localhost:8000/paste/.

   Vérifiez que la création fonctionne, et que vous pouvez maintenant ajouter, modifier ou supprimer des données via les fonctions accessibles par les nouvelles routes CRUD.

   Les boutons « Save » de validation des formulaires sont assez peu visibles pour l’instant, mais bien actifs.

   On corrigera cela plus tard.

   Il se peut que vous constatiez des problèmes de fonctionnement du contrôleur CRUD généré ci-dessus, avec une route inconnue pour le chemin /paste/. Il est alors nécessaire de corriger cela : il faut probablement à ce stade nettoyer à nouveau le cache de Symfony.

   symfony console cache:clear
   

   Si jamais ça ne suffisait pas (un bug Symfony semble empêcher parfois de faire fonctionner les nouvelles routes, malheureusement…), vous pouvez réinitialiser le projet Symfony un peu plus en profondeur :

   rm -fr var composer.lock symfony.lock vendor
   symfony composer install
   

4. Vérifiez bien que le formulaire d’ajout de nouvelle paste fonctionne enfin, en vérifiant l’impact sur la base de données : les pastes ajoutées sont bien retrouvées dans la liste, et ainsi de suite.

Dans le fonctionnement des formulaires de création d’entités pastes, la séquence d’interactions HTTP, est la suivante :

1. chargement du formulaire HTML de création (1ère requête : GET sur /paste/new)
2. soumission de données à la validation du formulaire (2ème requête : POST, encore sur /paste/new)
3. une fois la soumission traitée par l’application, redirection (automatique opérée par le navigateur) vers la liste des pastes (nouvelle requête GET, cette fois vers /paste/)

Vérifiez que c’est bien le cas :

1. dans le navigateur à l’aide du Moniteur réseau dans les outils du développeur Web, observez les requêtes pendant la création. La colonne « Méthode » indique s’il s’agit d’un GET ou d’un POST :

   

   Figure 1 : Trace des requêtes lors de la création dans le navigateur

   Observez en particulier les en-têtes transmis dans la réponse à la requête POST : en complément du code de réponse « 303 », le serveur envoie la cible de la redirection, dans l’en-tête Location.

2. Vérifiez aussi ce qui apparaît dans les logs du serveur HTTP (dans le terminal), où on voit passer ces 3 requêtes et les codes de réponse renvoyés (303 pour la redirection) :

   [PHP        ] ... [200]: GET /paste/new
   ...
   [PHP        ] ... [303]: POST /paste/new
   ...
   [PHP        ] ... [200]: GET /paste/
   

3. Observez également les caractéristiques du traitement de la requête POST via la barre d’outils Symfony (le Symfony profiler).

   Dans le coin inférieur droit de la page un popup affiche la dernière requête/réponse correspondant à l’état courant de la page :

   

   Figure 2 : Popup du profiler pour la page courante

   Il nous indique les éléments suivants :

   • on est bien en train de consulter la page de liste des pastes (affichée par PasteController::index), avec le code de réponse 200.
   • mais il nous indique aussi que c’est suite à un Redirect from consécutif au POST sur app_paste_new. À côté, il fournit un lien « (769960) » qui permet de cliquer pour accéder à l’outil des requêtes/réponses du profiler, directement sur cette requête POST précédente.

   Cela signifie qu’on a affiché cette page de liste des pastes (envoyée avec succès : 200), car le navigateur nous y a redirigé.

   La redirection a été provoquée car il avait reçu, juste avant, un code de réponse 303 en réponse à sa requête POST (qui avait été faite sur la route app_paste_new). Elle avait été traîtée par l’application Symfony qui lui a associé en interne, le jeton de requête (Token) « 769960 », dans cet exemple.

4. Dans l’outil de requêtes / réponses du Profiler Symfony, on retrouve les mêmes infos (plus détaillées) concernant cette dernière requête post-redirection :

   

   Figure 3 : Affichage de la requête dans le Profiler

   Remarquez que l’historique des requêtes précédamment traitées par Symfony est accessible derrière le lien « Last 10 ». On y retrouve nos 3 dernières requêtes de gestion du formulaire de création :

   

   Figure 4 : Dix dernières requêtes traitées par l’application

5. Cliquez sur ce lien de jeton de requête POST (ici « 769960 »).

   Vous voyez apparaître toutes les infos traîtées par Symfony concernant la requête POST de soumission des données, de façon similaire à ce que vous connaissez déjà pour les requêtes GET :

   • nom de la méthode du contrôleur invoquée : PasteController::new
   • données du POST :
     • content
     • created
     • …
   • etc.

   

   Figure 5 : Détails de la requête de soumission de données

6. Cliquez alors sur l’outil « Doctrine »

   Vous voyez alors, à la fin, la requête SQL qui a été générée :

   1. START TRANSACTION
   2. INSERT INTO paste (content, created, content_type) VALUES (?, ?, ?) ...
   3. COMMIT

   En cliquant sur « View runnable query«  on voit une version plus compréhensible de la requête SQL : INSERT INTO paste (content, created, content_type) VALUES ('Essai', '2024-08-09 10:10:00', NULL);

7. Cliquez sur l’outil « Forms » : vous voyez des détails sur les données qui ont été soumises depuis le formulaire HTML via la méthode POST, et la façon dont les champs du formulaire sont interfacés avec le modèle objet de l’entité Doctrine Paste.

   

   Figure 6 : Contenu du formulaire de données soumises, associées au modèle de données

Le générateur make:crud a créé pour nous des méthodes qui gèrent les requêtes GET et POST et le fonctionnement des formulaires.

Examinez dans votre IDE le code du contrôleur src/Controller/PasteController.php qui a été généré par l’assistant, qui correspond à ce qui a été présenté en cours magistral (une version un peu plus sophistiquée, certes).

1. Regardez le code des méthodes index() et show(), et en parallèle les gabarits Twig templates/paste/index.html.twig et templates/paste/show.html.twig.

   Vous ne devriez pas être trop dépaysés, par rapport à ce qu’on a utilisé jusqu’à présent dans TodoController.php.

2. Consultez maintenant le code de la méthode PasteController::new(), qui gère le formulaire de création de nouvelles Pastes. Il correspond à celui qu’on a présenté dans le cours.
3. Ajoutez des éléments de traces avec la fonction dump() pour tester et comprendre les différents éléments de ce code, aux différentes étapes de l’algorithme de traitement des soumissions : les données soumises, les entités du modèle. Vous devez retrouver parmi ces éléments ce que vous avez vu précédemment dans les outils du profiler Symfony

À ce stade, l’application fonctionne de façon interactive, et sauvegarde les opérations CRUD sur les Pastes, en base de données.

Le code généré est modifiable, si besoin, par exemple pour ajouter des opérations pour la gestion de règles métier.

Les gabarits générés n’utilisent probablement pas votre structure de gabarits et de blocs. Il va falloir faire quelques ajustements pour récupérer la mise en page standard de l’application.

On commence par la première fonction du CRUD : la création. On va tout simplement recopier les éléments correspondants générés par le maker pour les Pastes, dans le code gérant les Todo.

Procédez aux étapes suivantes, tout en testant au fur et à mesure vos modifications dans l’application :

1. Ajout d’une classe gestionnaire de formulaire / « type de données », TodoType définie dans le fichier src/Form/TodoType.php :

   • recopiez, dans votre IDE, le fichier PasteType.php et collez-le en tant que TodoType.php

     Notez qu’Eclipse propose de renommer le nom de la classe PasteType en TodoType pour l’aligner sur le nom du fichier. Pratique !

   • dans TodoType.php, modifiez le code pour renommer toutes les occurrences de la chaîne « Paste » en « Todo » (resp. « paste » en « todo ») : utilisez pour cela l’outil syntaxique « Edit / Find/replace »

   • modifiez la liste des champs ajoutés dans le constructeur de formulaire dans la méthode TodoType::buildForm, pour refléter les attributs de Todo :

     • title ;
     • created ;
     • updated ;

     Le reste des attributs pourra être vu plus tard.

2. Ajout d’une méthode new() dans TodoController :

   • copiez-collez le code de la méthode PasteController::new() pour l’ajouter dans TodoController.

     Dans certains contrôleurs, comme l’a fait le maker dans PasteController, il faut placer cette méthode new() avant la méthode show() dans le fichier source.

     Cela permet d’éviter une confusion dans le routage, pour ne pas essayer de charger la tâche d’identifiant « new » si on emprunte la route /todo/new, si la route « _show » a simplement comme motif de chemin '/{id}'.

     Dans notre cas, on avait déjà une définition du routage de TodoController::show(), qui spécifie bien le type de l’argument id attendu, donc pas de problème de confusion :

     #[Route('/{id}', name: 'todo_show', requirements: ['id' => '\d+'], methods: ['GET'])]
     public function show(Todo $todo): Response
     {
         // ...
     

     Explication : requirements: ['id' => '\d+'] permet de ne faire correspondre la route que si id contient un entier (« \d+ » est l’expression rationnelle pour signifier « succession de décimaux »).

   • modifiez toutes les occurrences de « Paste » en « Todo » (resp. « paste » en « todo »).

     Notez qu’Eclipse possède une fonction utile pour renommer une variable dans ses différentes occurrences dans le corps d’une méthode : positionnez le curseur dans la première chaîne $paste et sélectionnez le menu du bouton droit « Refactor / Rename ». Au fur et à mesure de la saisie du nouveau nom, vous voyez les autres occurrences de la variable être renommées simultanément. Cet outil est capable de reconnaître la sémantique du langage PHP pour agir au bons endroits, là où un outil syntaxique risquerait de tout casser.

     Certains autres IDE proposent une fonction similaire.

     Pensez à renommer les noms de gabarits ou de routes, qui ne sont que des chaînes de caractère, et pas des variables. Ils ne sont donc pas concernées par l’outil de renommage sémantique, qui ne s’applique qu’aux noms de classes, d’attributs ou de méthodes.

   • ajoutez les use manquants éventuels pour les classes inconnues jusqu’alors dans ce fichier (Request de Symfony\Component\HttpFoundation, EntityManagerInterface, …)
3. Ajout des gabarits du formulaire de création de nouvelle tâche :
   • recopiez les deux gabarits new.html.twig et _form.html.twig depuis templates/paste/ vers templates/todo/
   • renommez, dans templates/todo/new.html.twig toutes les occurrences de « Paste » en « Todo » (resp. « paste » en « todo »)

4. Testez que le formulaire de création de nouvelle tâche fonctionne.

   Résolvez les éventuelles erreurs liées aux attributs manquants signalées par Doctrine.

5. Ajoutez dans la page de liste des tâches (dans todo/index.html.twig) le lien de création, comme ça a été fait pour les Pastes

Vous constatez que pour obtenir un ensemble de pages parfait, il y a beaucoup de travail à faire sur ce genre de petits détails.

Ici, il ne s’agit pas d’obtenir une application Symfony « parfaite », car vous n’êtes probablement pas destinés à devenir des développeurs professionnels… la perfection peut attendre un peu !

Nous sommes partis du code tel que généré par make:crud pour les pastes pour faciliter le copier/coller. Le travail aurait été à peu près aussi difficile, s’il s’était agit de recopier les exemples de la documentation Symfony (par exemple depuis Forms).

Nous vous avons invité à faire toutes ces opérations, certes fastidieuses, pour qu’elles vous donnent l’occasion de tester en détail le fonctionnement des formulaires et de la mécanique sous-jacente, à l’aide des outils de mise-au-point présentés plus haut.

Il resterait maintenant à ajouter le code des méthodes restantes du CRUD : modification (edit()) et suppression (delete()) du contrôleur (voir la section optionnelle ci-dessous).