TA n°7-8 - Implémentation de formulaires pour entités liées
Importance de la contextualisation pour une application réelle

On souhaite tout d’abord pouvoir sauvegarder dans la base de données le fait qu’une tâche peut faire partie d’un projet.

Les formulaires actuels permettent de créer une tâche, mais pas de l’affecter à un projet à la création.

De la même façon on voudra pouvoir modifier les tâches existantes pour les ranger dans un projet.

Cela correspondra à gérer la saisie ou la mise à jour de la valeur de l’attribut Todo::project qu’on a jouté à l’étape précédente, dans les formulaires.

1. Chargez la page d’ajout d’une nouvelle tâche /todo/new. Déroulez l’ajout et observez dans le Profiler Symfony le détail de la gestion du formulaire (Form) dans la requête POST de soumission des données.

   On voit que le Form ne contient que les anciens champs, mais pas le nouveau champ project.

   Par contre, le Normalized Format qui génère les données Doctrine sous forme de Todo (App\Entity\Todo) nous montre les valeurs pour l’entité actuelle :

   App\Entity\Todo {#525 ▼
     -id: 5
     -title: "whatever"
     -completed: false
     -created: DateTime @1724858066 {#526 ▶}
     -updated: DateTime @1724858066 {#527 ▶}
     -tags: Doctrine\ORM\PersistentCollection {#766 …}
     -project: null
   }
   

   En mémoire, la tâche a un champ project nul, puisqu’il n’est pas renseignable dans le formulaire.

2. Modifiez en conséquence la classe de gestion du formulaire de modification des tâches (TodoType, dans src/Form/), pour ajouter un champ project dans le formbuilder :

   $builder
        ->add('project');
   

3. Testez dans l’application pour ouvrir le formulaire de modification de tâches d’une tâche créée juste auparavant.

   Normalement, à ce stade, le formulaire fonctionne, proposant une liste de projets vide : normal, nous n’avons pas encore saisi de projets dans la base.

   

   Figure 1 : Champs du formulaire de création de nouvelle tâche

4. Ajoutez maintenant un nouveau projet dans la base de données via le formulaire de création de nouveau projet.

5. Retournez créer une tâche.

   Normalement, vous devriez constater une erreur à l’ouverture du formulaire d’édition de la tâche : « Object of class App\Entity\Project could not be converted to string ».

   La construction du formulaire, très basique, doit en effet afficher la liste des projets dans la liste de saisie vue plus haut. Pour cela, elle doit les afficher sous forme de chaîne de caractères dans cette liste…

   Modifiez en conséquence la classe Project pour ajouter une méthode __toString(). Vous pouvez vous inspirer d’une autre méthode __toString() déjà présente dans une autre classe du modèle des données.

6. Vérifiez que la création ou modification des tâches fonctionne enfin, permettant d’y définir le projet d’une tâche.
7. Utilisez la barre d’outils Symfony pour examiner dans le Profiler le comportement de la requête POST de soumission des données modifiées.

   • Dans l’outil Forms vous devriez voir que le champ project est bien renseigné et que les données Doctrine sont correctement modifiées en mémoire :

     App\Entity\Todo {#525 ▼
       -id: 7
       -title: "Ajouter une association 1-N"
       -completed: false
       -created: DateTime @1724859017 {#526 ▶}
       -updated: DateTime @1724859017 {#527 ▶}
       -tags: Doctrine\ORM\PersistentCollection {#840 …}
       -project: App\Entity\Project {#937 ▶}
     }
     

     si vous dépliez le contenu de la propriété project (« #937 », dans cet exemple), vous verrez la valeur du projet référencé :

     App\Entity\Todo {#525 ▼
       -id: 7
       -title: "Ajouter une association 1-N"
       -completed: false
       -created: DateTime @1724859017 {#526 ▶}
       -updated: DateTime @1724859017 {#527 ▶}
       -tags: Doctrine\ORM\PersistentCollection {#840 …}
       -project: App\Entity\Project {#937 ▼
         -id: 2
         -title: "Beau projet"
         -description: "Car c'est notre projet !"
         -todos: Doctrine\ORM\PersistentCollection {#931 …}
       }
     }
     

     On a bien une entité Doctrine Todo qui fait référence à son projet, une instance de Project.

   • Dans l’outil Doctrine, vous devriez voir la requête INSERT.

     En version « /runnable » :

     INSERT INTO todo
            (title, completed, created, updated, project_id)
     VALUES
             ('Ajouter une association 1-N', 0, '2024-08-28 15:30:17',
              '2024-08-28 15:30:17', 2);
     

     La clé étrangère du projet (project_id) est bien renseignée à la valeur de l’id du projet (ici « 2 ») : le nouveau champ fonctionne.

8. Vous pouvez maintenant vérifier aussi avec un dump() que les liens vers les projets des tâches sont bien définis, même si on ne les affiche pas encore.

   Modifiez par exemple templates/todo/index.html.twig pour ajouter un {% dump todo %} à l’intérieur du {% for todo in todos %}.

   L’affichage du dump doit ressembler à ceci, pour les tâches qu’on a affectée à un projet :

   App\Entity\Todo {#640 ▼
     -id: 7
     -title: "Ajouter une association 1-N"
     -completed: false
     -created: DateTime @1724859017 {#638 ▶}
     -updated: DateTime @1724859017 {#639 ▶}
     -tags: Doctrine\ORM\PersistentCollection {#641 ▶}
     -project: Proxies\__CG__\App\Entity\Project {#634 ▼
       -id: 2
       -title: ? ?string
       -description: ? ?string
       -todos: ? Doctrine\Common\Collections\Collection
       -lazyObjectState: Symfony\Component\VarExporter\Internal\LazyObjectState {#635 ▶}
     }
   }
   

   Remarquez que tant qu’on n’a pas accédé aux attributs d’un projet, l’attribut interne todo:project référence une entité « proxy », qui n’est pas initialisée (__isInitialized__), mais porte bien l’identifiant du projet concerné (id).

   C’est le mécanisme de chargement paraisseux dont nous parlerons en cours. Tant qu’on n’accède pas aux attributs du Project, inutile de charger ses données depuis la base de données.

Modifiez le gabarit d’affichage d’une tâche pour afficher son projet, s’il est renseigné.

1. Modifiez templates/todo/show.html.twig pour ajouter l’affichage de l’attribut todo.project. Vous pouvez spécialiser l’affichage, au cas où il n’y a pas de projet pour une tâche, avec un bloc if :

   {%  if todo.project %}
      Projet : {{ todo.project }}
   {% endif %}
   

2. Comparez l’affichage entre tâches d’un projet ou tâches isolées. La section optionnelle devrait s’afficher comme souhaité.

3. Modifiez le gabarit pour ajouter des dump() pour afficher l’état de la tâche, et de la référence à son projet en mémoire, à différents endroits au début du gabarit : à la fois avant, et après l’affichage de l’attribut todo.project :

   {% dump todo %}
   
   {# todo.project avant consultation de ses attributs #}
   {% dump todo.project %}
   
   {% if todo.project %}
   
      {# affichage dans le gabarit #}
      Projet : {{ todo.project }}
   
      {% dump todo %}
   
   {% endif %}
   

4. Testez l’affichage de la page pour une tâche ayant un projet.

   1. Regardez les deux premiers dumps faits avant l’accès au champ todo.project pour son affichage effectif dans la page, avec {{ todo.project }} : normalement, il s’agit, comme dans l’étape précédente, d’une entité Proxy non initialisée (« #535 »).

      App\Entity\Todo {#493 ▼
        -id: 7
        -title: "Ajouter une association 1-N"
        -completed: false
        -created: DateTime @1724859017 {#487 ▶}
        -updated: DateTime @1724859017 {#478 ▶}
        -tags: Doctrine\ORM\PersistentCollection {#508 ▶}
        -project: Proxies\__CG__\App\Entity\Project {#535 ▼
          -id: 2
          -title: ? ?string
          -description: ? ?string
          -todos: ? Doctrine\Common\Collections\Collection
          -lazyObjectState: Symfony\Component\VarExporter\Internal\LazyObjectState {#536 ▶}
        }
      }
      

   2. Regardez maintenant le 3ème dump. Cette fois, comme l’objet a dû être affiché, dans le contenu de la page, Twig a provoqué l’accès réel à l’objet depuis la base de données.

      App\Entity\Todo {#493 ▼
        -id: 7
        -title: "Ajouter une association 1-N"
        -completed: false
        -created: DateTime @1724859017 {#487 ▶}
        -updated: DateTime @1724859017 {#478 ▶}
        -tags: Doctrine\ORM\PersistentCollection {#508 ▶}
        -project: Proxies\__CG__\App\Entity\Project {#535 ▼
          -id: 2
          -title: "Beau projet"
          -description: "Car c'est notre projet !"
          -todos: Doctrine\ORM\PersistentCollection {#1194 ▶}
          -lazyObjectState: Symfony\Component\VarExporter\Internal\LazyObjectState {#536 ▶}
        }
      }
      

      Cette fois, la classe Proxy est initialisée, et les valeurs des attributs du Project autres que l’id sont bien renseignés à leurs valeurs.

   3. Regardez, dans l’outil Doctrine de la barre Symfony, les requêtes qui sont faites en base : pour cette même tâche ayant un projet, il y a 2 requêtes :

      • pour charger la tâche (au déclenchement de la méthode show()) :

        SELECT
          t0.id AS id_1,
          t0.title AS title_2,
          t0.completed AS completed_3,
          t0.created AS created_4,
          t0.updated AS updated_5,
          t0.project_id AS project_id_6
        FROM
          todo t0
        WHERE
          t0.id = '7';
        

        C’est cet état qu’on voit dans les premiers dumps. On n’a connaissance que de la propriété project_id

      • et la deuxième, plus tardive, pour initialiser l’instance de Project, puisqu’il s’agit de l’afficher dans le gabarit, c’est à dire appeler Project::_toString() :

        SELECT
          t0.id AS id_1,
          t0.title AS title_2,
          t0.description AS description_3
        FROM
          project t0
        WHERE
          t0.id = 2;
        

   4. Comparez avec l’affichage d’une tâche n’ayant pas de projet. En toute logique, on voit bien qu’on ne fait qu’une requête.

Vous voyez clairement à l’œuvre le mécanisme de Lazy loading, avec le patron de conception Proxy utilisé par Doctrine.

Maintenant que vous pouvez renseigner en base de données des liens entre tâches et projets, vous pouvez ajouter l’affichage de la liste des tâches d’un projet, dans le gabarit de la fiche de consultation d’un projet (templates/project/show.html.twig) :

{% dump(project) %}

{# FIXME: display the project todos
{% for todo in ... %}
...
   <a href="{{ path('app_todo_show', {'id' : todo.id}) }}">{{ todo.title }}</a>
...
{% else %}
   <em>no tasks found</em>
{% endfor %}
/FIXME #}

Ajoutez dans la page de consultation de toutes les tâches, une colonne permettant l’affichage du projet, s’il est défini (gabarit templates/todo/index.html.twig).

Vous pouvez maintenant compléter les pages existantes pour permettre de passer de la consultation d’une tâche à son projet (s’il existe), et compléter ainsi la navigation dans le modèle de données.

Modifiez templates/todo/show.html.twig pour compléter l’affichage de todo.project sous forme de lien (en vous inspirant de ce qui vient d’être fait pour le lien inverse de projet à tâche, avec path()).

Attention : l’application doit continuer de fonctionner aussi bien pour des tâches ayant un projet, que pour des tâches sans projet.

Modifiez le gabarit d’affichage d’un projet, pour ajouter, en dessous de la liste des tâches du projet, un lien vers un formulaire (que nous allons ajouter juste après).

Modifiez templates/project/show.html.twig pour ajouter un lien du type :

<tr>
        <th>Tâches</th>
        <td>
                <ul>
                  {% for todo in project.todos %}
                  ...
                  {% else %}
                  ...
                  {% endfor %}
                </ul>
                  {# CHANGEZ le nom de route une fois le formulaire de création de tâche ajouté #}
                  <a href="{{ path('app_project_show', {'id' : project.id}) }}">add new task</a>
        </td>
</tr>

Pour l’instant, le lien pointe sur la même page. On le modifiera plus tard, une fois ajouté la gestion du formulaire de nouvelle tâche.

Comme on connaît le projet en cours de consultation, on va directement invoquer l’ajout d’une tâche à ce projet, en utilisant un nouveau formulaire d’ajout de tâche ayant connaissance du projet courant.

Ajoutez différents éléments au code de l’application :

1. créez un nouveau gabarit nommé todo/newinproject.html.twig, sur le modèle de todo/new.html.twig;

2. ajoutez une méthode TodoController::newInProject() reprenant certains éléments de TodoController::new(), mais ajoutant une todo à un projet existant

   Son code correspond à ce qui suit :

   //...
   use App\Entity\Project;
   
        //...
   
        #[Route('/newinproject/{id}', name: 'app_todo_newinproject', methods: ['GET', 'POST'])]
        public function newInProject(Request $request, EntityManagerInterface $entityManager, Project $project): Response
        {
                $todo = new Todo();
                // already set a project, so as to not need add that field in the form (in TodoType)
                $todo->setProject($project);
   
                $form = $this->createForm(...);
                //...
                if ($form->isSubmitted() && $form->isValid()) {
                        //...
                        return $this->redirectToRoute('app_project_show',
                                                      ['id' => $project->getId()],
                                                      Response::HTTP_SEE_OTHER);
                }
   
                return $this->render('todo/newinproject.html.twig', [
                        'project' => $project,
                        'todo' => $todo,
                        'form' => $form,
                ]);
        }
   

   Remarquons quelques faits marquants sur ce code :

   • le chemin de cette nouvelle route, /todo/newinproject/{id}, est dérivé de /todo, le préfixe de la classe TodoController qui gère les tâches (on aurait pu faire le choix de le placer dans ProjectController mais ça aurait été peu judicieux car tirant trop de liens avec l’entité Todo)

   • on effectue un passage d’argument de l’instance du projet dans l’appel (un objet $project de type Project), qui est généré « automagiquement » en chargeant un projet ayant pour identifiant le numéro id extrait du chemin de la route (/todo/newinproject/{id}) via la fonctionnalité d’Entity Value Resolver de Symfony.

     Ce mécanisme est essentiel pour écrire du code très compact. C’est le même qui est utilisé pour app_project_show :

     L’Entity Value Resolver effectue le chargement des données depuis la base via Doctrine automatiquement, sans avoir besoin de faire un ->find($id).

   • ajout de la Todo à son Project si les données soumises sont correctes :

     $todo->setProject($project);
     

     On utilise ici la méthode du modèle doctrine générée par make:entity en cas d’association OneToMany.

   • comme pour new(), on effectue un appel à persist() (qui sert à « taguer » une entité du modèle comme devant être sauvée en base) uniquement sur la nouvelle Todo. Oui, et alors ?

     Mieux vaut vérifier : ici, on a défini un projet pour la tâche. Qui doit être sauvegardé en base ? Le projet doit-il être modifié suite à l’ajout de cette tâche ?

     Dans cette configuration, c’est la tâche qui contient la référence vers son projet, mais l’inverse n’est pas vrai : l’entité projet n’est pas modifiée. En base de données, cette association OneToMany s’est traduite par la clé étrangère de Project migrée dans Todo.

     On ne doit donc bien faire qu’un persist() sur cette nouvelle Todo, comme dans new(). On en est sûrs, cette fois.

   • Une fois ajouté la nouvelle Todo dans la base de données, on doit rediriger vers le point de départ (en principe) de l’accès à ce nouveau dialogue. C’est différent du code de new() on doit aller vers la page de consultation du projet, donc la route app_project_show, qui attend un argument. On donc on doit appeler getId() sur $project pour construire la route correcte;
   • Notez qu’on passe le projet directement au gabarit todo/newinproject.html.twig, ce qui permet de le customiser par rapport au précédent gabarit new.html.twig;
3. Modifiez enfin le gabarit templates/project/show.html.twig pour appeler la bonne route dans le lien d’ajout de la tâche qu’on avait ajouté un peu plus tôt (on veut la nouvelle route app_todo_newinproject).
4. Vérifiez que ça fonctionne. En cas de soucis, vous connaissez maintenant les outils facilitant la mise-au-point :
   • vous pouvez ajouter des dump(), dans le code PHP, ou dans les gabarits
   • vous pouvez aussi vérifier les requêtes transmises via le Profiler dans les outils du développeur Symfony. Vous y trouverez aussi la gestion des formulaires, et les requêtes transmises à la base de données par Doctrine.

5. Quand ça fonctionne, modifiez enfin le gabarit de nouvelle tâche pour contextualiser, par exemple avec :

   <h1>Add a Todo to {{ project }}</h1>
   

   En passant, le sous-formulaire de todo/_form.html.twig n’a pas eu besoin d’être modifié : on peut toujours créer des todos sans projets (autorisé dans le modèle de données) si on passe par /todo/new.

Par exemple, dans une application réelle, où cette fois, les Projets seraient composés de tâches, et où toute tâche devrait appartenir au projet, on ne pourrait plus créer des tâches sans avoir de projet comme point de départ.

On ferait bien-sûr évoluer le modèle de données pour que le champ correspondant à l’association vers le projet d’une tâche ne puisse être nul. Cela garantirait la cohérence des données.

Il est tout aussi indispensable de gérer de telles relations structurantes quand on est sur une application multi-utilisateurs, pour ne pas mélanger les données de différents utilisateurs.

On réalisera donc de nombreuses adaptations similaires à cette contextualisation :

• au niveau du chargement des données : données du bon utilisateur, ou dans le bon sous-contexte passé en paramètres de la route;
• et au niveau de la définition des valeurs des attributs pour les nouvelles entités : encore une fois en fonction du contexte implicite (utilisateur courant connecté), ou explicite, en fonction des arguments passés aux routes.