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.

1. Chargez la page d’ajout d’une nouvelle tâche /todo/new

   Le formulaire permet de créer une tâche, mais pas de l’affecter à un projet à la création. De la même façon il faut permettre de modifier les tâches pour renseigner la valeur de l’attribut Todo::project qu’on a jouté à l’étape précédente.

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.

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.

4. Ajoutez maintenant un nouveau projet.

5. Retournez modifier une tâche. Normalement, vous devriez constater une erreur : la construction du formulaire, très basique, doit afficher la liste des projets dans une liste, et pour cela, elle doit les afficher sous forme de chaîne de caractères.

   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 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 le comportement de la requête POST de soumission des données modifiées dans le formulaire de modification de tâche (remontez à la requête POST précédent la redirection en cliquant sur le token de la requête précédente).

   Vous devriez voir, dans l’outil Doctrine la requête UPDATE du type UPDATE todos SET updated = ?, project_id = ? WHERE tid = ?. La clé étrangère du projet est bien modifiée : 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 {#682 ▼
     -id: 5
     -title: "..."
     -completed: false
     -created: DateTime @1666943460 {#680 ▶}
     -updated: DateTime @1666944055 {#681 ▶}
     -project: Proxies\__CG__\App\Entity\Project {#701 ▼
       +__isInitialized__: false
       -id: 1
       -title: null
       -description: null
       -todos: null
        …2
     }
   }
   

   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 %}
    ...
   {% endif %}
   

2. Comparez l’affichage entre tâches d’un projet ou tâches isolées

3. Modifiez le gabarit pour ajouter des dump pour afficher la tâche en mémoire, au début du gabarit (avant l’affichage de son projet), et après l’affichage de l’attribut project :

   {% dump todo %}
   {% dump todo.project %}
   
   ...
   
   {%  if todo.project %}
      ...
   
      {{ 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.
   2. Regardez maintenant le dernier dump. Cette fois, comme l’objet a dû être affiché, Twig a provoqué l’accès réel à l’objet depuis la base de données. Cette fois, la classe Proxy est initialisée (__isInitialized__: true), 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 :
      • « SELECT t0.tid AS tid_1, t0.title AS title_2, [...] FROM todos t0 WHERE t0.tid = ? » pour charger la tâche
      • et la deuxième, plus tardive, « SELECT t0.id AS id_1, t0.title AS title_2, [...] FROM project t0 WHERE t0.id = ? » pour charger son projet, pisqu’il s’agit de l’afficher.
   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 le mécanisme de Lazy loading à l’œuvre, 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 l’affichage du projet (s’il est défini) dans la ligne affichant chaque tâche, dans la page de consultation de toutes les tâches (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->createView(),
                ]);
        }
   

   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.

   • Attention, une fois ajouté la nouvelle Todo, on redirige vers le point de départ (en principe) de l’accès à ce nouveau dialogue : la consultation du projet, donc la route app_project_show (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;
   • Notez que 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.

3. Modifiez enfin le gabarit templates/project/show.html.twig pour appeler cette nouvelle route app_todo_newinproject dans le lien d’ajout de la tâche.

   Vérifiez que ça fonctionne (vous pouvez ajouter des dump(), et vérifier les requêtes transmises à la base de données dans les outils du développeur Symfony.

4. Modifiez enfin le gabarit de nouvelle tâche pour contextualiser, par exemple avec :

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

Vous avez vu ci-dessus un élément clé pour la gestion des entités liées par une association 1-N (OneToMany).

Vous pouvez raffiner un peu la gestion de ce formulaire d’ajout d’une nouvelle tâche à un projet, afin de ne pas afficher le champ de modification du projet dans le formulaire HTML, puisque, dans ce cas, le projet est fixé.

Cette amélioration n’est pas cruciale, donc vous pouvez passer à la suite, si vous êtes pressés par le temps restant dans la séance de TP.

Actuellement l’ajout du champ est réalisé dans TodoType::buildForm() :

$builder
 ->add('title')
 ->add('project');
 ...

On peut modificer ce comportement, mais attention, car la génération du formulaire s’applique aussi bien à la création (via new() ou newInProject()) qu’à la modification…

Une solution consiste à dupliquer la classe TodoType pour réaliser une classe TodoAddType ayant un comportement différent, spécifique à cette méthode add().

Une autre solution consiste à garder une seule classe TodoType, et à utiliser le mécanisme des options, qu’on a déjà utilisé pour l’affichage optionnel du statut terminé de la tâche (dans une partie optionnelle d’une séance précédente), mais en l’adaptant à ce nouveau contexte.

1. Modifiez le code de la méthode TodoController::newInProject() pour gérer le passage de l’option display_project.

   Modifiez le code dans la méthode new(), qui appelle la génération du formulaire, pour passer en argument un tableau d’options, qui contient la valeur de l’option display_project, qui doit alors être fausse :

   public function newInProject(Request $request, EntityManagerInterface $entityManager, Project $project): Response
   {
      $todo = new Todo();
      $todo->setProject($project);
      //...
   
      $form = $this->createForm(TodoType::class, $todo,
              [
                'display_project' => false,
                //...
              ]
              );
   

2. Modifiez le code du gestionnaire de formulaire TodoType pour n’afficher le champ de formulaire que pour les tâches modifiables

   1. Ajoutez-lui une option, via la méthode configureOptions(), nommée display_project de type booléen, dont la valeur par défaut est fausse :

      public function configureOptions(OptionsResolver $resolver)
      {
        $resolver->setDefaults([
                'data_class' => Todo::class,
                'display_project' => true
        ]);
        $resolver->setAllowedTypes('display_project', 'bool');
      }
      

   2. Modifiez le comportement de la création du formulaire, dans buildForm() pour ajouter ou non certains champs, selon qu’ils doivent être inclus dans le formulaire, en fonction de la valeur de display_project :

      public function buildForm(FormBuilderInterface $builder, array $options): void
      {
         ...
         if($options['display_project'] ) 
         {
             $builder->add('project');
         }
         $builder->add(...);
      
         ...
      

3. Testez que le champ de sélection du projet a bien disparu quand on crée la tâche dans le contexte du projet.

   Vérifiez néanmoins que même si le champ n’est plus affiché, il est bien sauvegardé en base de données.

4. Testez la création d’une tâche sans projet, en repassant par /todo/new, pour vérifier que la modification de TodoType n’a pas cassé le mécanisme d’ajout de tâches isolées.

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.