TP n°9 - Formulaires dynamiques complexes
Formulaires Symfony dynamiques - Doctrine et JQuery en détails

Vous allez modifier la version de ToDo, supposée être dans l’état final obtenu à la fin de la séance 8.

• Si vous aviez terminé la séance précédente, nous vous recommendons de travailler dans une copie du répertoire :

  cd $HOME/CSC4101/
  mkdir tp-09
  cp -r tp-08/todo-app tp-09/
  cd tp-09/todo-app/
  rm -fr .project
  symfony console cache:clear
  

  Pensez éventuellement à supprimer aussi les répertoires des vieilles séances (tp-N-2) pour libérer un peu d’espace disque.

  Recréez un nouveau projet dans Eclipse pour la nouvelle version de ToDo de la présente séance.

• En cas de besoin, si vous n’aviez pas pu effectuer les modifications complètement dans la séance précédente, et aviez un état instable dans le répertoire de travail de la séance 8, vous pouvez récupérer le code correspondant au travail terminé de la séance 8 :

  mkdir -p $HOME/CSC4101/tp-09
  cd $HOME/CSC4101/tp-09/
  symfony composer create-project oberger/tspcsc4101-todo-skeleton todo-app "v8.*"
  

  Confirmez l’application de la recette Flex pour vich/uploader-bundle en répondant ’y’ (yes) au prompt de composer.

  Puis importez le projet dans Eclipse.

  Profitez-en pour faire éventuellement du ménage dans les anciennes versions (TP n-2 et antérieures)

Procédez aux étapes suivantes :

1. dans src/Controller/ProjectController.php, modifiez la méthode new() existante, pour ajouter le code bidon suivant.

   Attention à bien placer les différents blocs dans le bon ordre, comme ci-dessous

   use App\Entity\Todo;
   
   //...
   
    /**
     * @Route("/new", name="project_new", methods="GET|POST")
     */
    public function new(Request $request): Response
    {
        // 1) création d'un projet en mémoire
        $project = new Project();
   
        // 2) ajout de sous-entités
        // code bidon - c'est juste fait pour qu'un Project ait des todos
        // sinon, ça ne sert pas à grand chose
        $todo1 = new Todo();
        $todo1->setTitle('todo1');
        $project->getTodos()->add($todo1);
        $todo2 = new Todo();
        $todo2->setTitle('todo2');
        $project->getTodos()->add($todo2);
        // fin du code bidon
   
        // 3) création d'un formulaire d'affichage du projet
        //    et de ses sous-tâches
        $form = $this->createForm(ProjectType::class, $project);
   
        ...
    }
   

   Dès qu’un projet est créé, en support de l’affichage du formulaire de création, il comportera deux sous-tâches de test.

2. modifiez la méthode ProjectType::buildForm (dans src/Form/ProjectType.php) pour gérer l’intégration dans le formulaire de modification d’un projet, de sous-formulaires pour ses sous-tâches :

   use Symfony\Component\Form\Extension\Core\Type\CollectionType;
   //...
       public function buildForm(FormBuilderInterface $builder, array $options)
       {
           $builder
               ->add('title')
               ->add('description')
               ->add('todos', CollectionType::class, array(
                   'entry_type' => TodoType::class,
                   'entry_options' => array('label' => false),
               ));
           ;
       }
   

   Vous voyez ici comment on intègre un nouvel élément au formulaire, pour gérer la collection des sous-tâches de l’attribut todos des Project.

   Au lieu d’une gestion d’un champ de saisie mono-valuée, comme pour le titre du projet (title), il s’agit ici d’un objet Symfony gérant une collection (CollectionType). Chaque élément de la collection sera géré par un sous-formulaire de type TodoType (il existe déjà, et est utilisé pour la création des tâches). Ignorez le rôle d’entry_options qui est un détail d’implémentation.

3. Vérifiez que le formulaire de création de nouveau projet s’affiche, et permet d’y voir les deux sous-tâches « bidon ».

Il faut maintenant adapter le code du gabarit associé, pour intégrer la dimension dynamique du formulaire HTML.

Procédez aux étapes suivantes :

1. On va modifier le gabarit de base project/project_form_base.html.twig. Dans le bloc custompage_script Twig, dans les balises <script>, on ajoute le code JQuery suivant :

   var $collectionHolder;
   
   //setup an "add a todo" link
   var $addTodoButton = $('<button type="button" class="add_todo_link">Add a task</button>');
   var $newLinkLi = $('<li></li>').append($addTodoButton);
   
   jQuery(document).ready(function() {
    // Get the ul that holds the collection of todos
    $collectionHolder = $('ul.todos');
   
    // add the "add a todo" anchor and li to the todos ul
    $collectionHolder.append($newLinkLi);
   
    // count the current form inputs we have (e.g. 2), use that as the new
    // index when inserting a new item (e.g. 2)
    $collectionHolder.data('index', $collectionHolder.find(':input').length);
   
    $addTodoButton.on('click', function(e) {
        // add a new todo form (see next code block)
        addTodoForm($collectionHolder, $newLinkLi);
    });
   });
   
   function addTodoForm($collectionHolder, $newLinkLi) {
       // Get the data-prototype explained earlier
       var prototype = $collectionHolder.data('prototype');
   
       // get the new index
       var index = $collectionHolder.data('index');
   
       var newForm = prototype;
       // You need this only if you didn't set 'label' => false in your taskss field in TaskType
       // Replace '__name__label__' in the prototype's HTML to
       // instead be a number based on how many items we have
       // newForm = newForm.replace(/__name__label__/g, index);
   
       // Replace '__name__' in the prototype's HTML to
       // instead be a number based on how many items we have
       newForm = newForm.replace(/__name__/g, index);
   
       // increase the index with one for the next item
       $collectionHolder.data('index', index + 1);
   
       // Display the form in the page in an li, before the "Add a task" link li
       var $newFormLi = $('<li></li>').append(newForm);
       $newLinkLi.before($newFormLi);
   }
   

   Ce code peut sembler un peu compliqué, mais il est en fait relativement simple, pourvu qu’on ait compris le principe de la phase précédente où on a embarqué dans le formulaire HTML l’attribut data-prototype, tel que généré par Symfony.

   addTodoForm() va convertir ce prototype en code HTML, qui sera ajouté dans le DOM du formulaire, pour faire apparaître au bon endroit les sous-champs d’ajout d’une tâche, en remplaçant les identifiants des différentes balises des formulaires, là où le prototype contenait __name__.

   Référez-vous si besoin à la documentation Symfony qui explique bien les détails de ce code.

2. Testez le fonctionnement du bouton « Ajouter une tâche », pour vérifier que l’ajout d’un sous-formulaire est opérationnel. Vérifiez dans le DOM, via l’inspecteur des outils de développement du navigateur, que les sous-formulaires sont ajoutés dynamiquement comme on le souhaite (de la même façon que lorsqu’ils sont déjà présents pour les tâches « bidon »).

Vous avez ici un exemple de la façon dont un réflexe Javascript sait modifier dynamiquement le contenu d’une page, pour changer à la demande le contenu d’un formulaire. La structure du formulaire, préparée à l’avance dans le prototype, généré par le serveur, n’est pas complètement construite par le code Javascript. Le formulaire reste sous un contrôle assez important du code Symfony.

Procédez aux modifications suivantes :

1. Ajoutez dans la classe de formulaire des Projets, une option supplémentaire (allow_delete) permettant d’autoriser la suppression des sous-formulaires :

   public function buildForm(FormBuilderInterface $builder, array $options)
       {
           $builder
               ->add('todos', CollectionType::class, array(
                   ...
                   'allow_delete' => true,
               ));
           ;
       }
   

2. Modifiez le code JQuery correspondant pour ajouter des liens de suppression de sous-formulaires de saisie de tâches. Insérez le code correspondant qui modifiee tous les <li> des tâches, puis le code de addTodoForm() pour invoquer une nouvelle fonction addTodoFormDeleteLink( ), pour obtenir du code similaire à ce qui suit :

   var $collectionHolder;
   
   //setup an "add a task" link
   var $addTodoButton = $('<button type="button" class="add_todo_link">Add a task</button>');
   var $newLinkLi = $('<li></li>').append($addTodoButton);
   
   jQuery(document).ready(function() {
    // Get the ul that holds the collection of tasks
    $collectionHolder = $('ul.todos');
   
   //add a delete link to all of the existing task form li elements
    $collectionHolder.find('li').each(function() {
        addTodoFormDeleteLink($(this));
    });
   
    // add the "add a task" anchor and li to the tasks ul
    $collectionHolder.append($newLinkLi);
   
       ...
   });
   
   function addTodoForm($collectionHolder, $newLinkLi) {
       ...
       // Display the form in the page in an li, before the "Add a task" link li
       var $newFormLi = $('<li></li>').append(newForm);
   
       // add a delete link to the new form
       addTodoFormDeleteLink($newFormLi);
   
       $newLinkLi.before($newFormLi);
   }
   
   function addTodoFormDeleteLink($todoFormLi) {
       var $removeFormButton = $('<button type="button">Delete this task</button>');
       $todoFormLi.append($removeFormButton);
   
       $removeFormButton.on('click', function(e) {
           // remove the li for the todo form
           $todoFormLi.remove();
       });
   }
   
   

3. Testez le fonctionnement des liens de suppression et leur impact sur le DOM de la page.

Lors des mises à jour des données, à la validation des formulaires de modification des projets, on s’attend à ce que les modifications sur les données des projets soient sauvées, mais aussi les ajouts, modifications ou suppressions des données de leurs tâches, venant des sous-formulaires Todo embarqués dynamiquement dans le formulaire.

Si les formulaires fonctionnent correctement, les méthodes new et edit du contrôleur ProjectController reçoivent les bonnes données.

Contrôlez que les données transmises dans les formulaires sont cohérentes, après des ajouts ou suppressions de sous-formulaires de Todos :

1. dans le Profiler de la barre d’outils Symfony, vous allez examiner les requêtes POST (antérieures à la redirection, en cas de succès) en remontant dans l’historique des requêtes.
2. les données soumises dans une requête POST sont visibles dans le menu Forms : il doit y avoir le bon nombre de sous formulaires des todos dans la hiérarchie :
   • project
   • title
   • description
   • todos, qui contient bien une collection de tâches :
     • 1
     • 2
     • …
3. si le formulaire a été accepté sans problème, vérifiez les requêtes transmises à la base de données par Doctrine, suite aux traitements du formulaire (valide), dans le menu « Doctrine ».

Si le formulaire fonctionnait correctement, des requêtes INSERT, UPDATE ou DELETE devraient être faites dans la base de données, dans la table todos, pour gérer l’ajout, la modification ou la suppression des sous-tâches des projets.

Or normalement, à ce stade, les données ne sont pas sauvegardées correctement. Seule la table des projets est toujours gérée.

On va corriger le code pour s’assurer de la bonne sauvegarde.

L’ajout d’une sous-tâche devrait afficher une erreur 500 du type « A new entity was found through the relationship ’App\Entity\Project#todos’ that was not configured to cascade persist operations for entity »

Notez que l’erreur de produit dans l’appel à $em->flush();, soit au niveau de la tentative de génération des requêtes à envoyer à la base de données, dans Doctrine.

1. Procédez à l’examen des données des formulaires, comme indiqué ci-dessus. Il doit bien y avoir le bon nombre de sous-tâches dans les sous-formulaires todos.
2. Examinez le message d’erreur complet, qui propose une solution pour remédier au problème.
3. Procédez aux modifications suggérées en ajoutant cascade={"persist"} dans l’annotation Doctrine @ORM\OneToMany de Project:todos dans src/Entity/Project.php.
4. Vérifiez que cela fonctionne correctement maintenant, en revenant dans le Profiler sur la requête POST, et en examinant les requêtes.

Y a-t-il les INSERT INTO todos attendus ? Cela doit maintenant fonctionner.

L’explication du problème qu’on vient de résoudre est donnée dans la documentation, dans la « bloc » « Doctrine: Cascading Relations and saving the « Inverse » side » de https://symfony.com/doc/current/form/form_collections.html#allowing-new-tags-with-the-prototype.

Dans la gestion de la soumission du formulaire, le code gérant l’ajout des données des formulaires dans les entités en mémoire est invoqué dans $form->isValid() : cela invoque Project:addTodo() pour chaque sous-formulaire des todos.

Examinez Project:addTodo(), et remarquez le code :

$this->todos[] = $todo;
$todo->setProject($this);

• la première ligne ajoute le nouveau todo dans la collection des todos de ce projet,
• puis elle met à jour le pointeur inverse, du Todo vers son Project.

De nouvelles entités sont donc présentes en mémoire dans App\Entity\Project#todos, comme nous l’indique Doctrine dans le message d’erreur.

Mais si on examine le code traitant les données du formulaire dans le contrôleur (entre $form->isValid() et l’endoit où se produit l’erreur : $em->flush();), on peut vérifier quelles sont les données qui doivent être sauvegardées, puisqu’elles sont « marquées » comme telles avec l’appel à $em->persist($project);. Seul le projet est marqué.

Comme indiqué dans la documentation, soit ce persist() doit procéder « en cascade », en parcourant l’arbre des données liées depuis l’instance de $project, ce qui sera fait à condition d’avoir déclaré l’attribut todos de Project avec cascade={"persist"}.

Ou bien, on devrait écrire une boucle pour appeler persist( ) explicitement pour chaque élément de $project->getTodos(). L’annotation est beaucoup plus pratique, dans ce cas. Consultez la documentation doctrine pour plus de détails.

Maintenant que l’ajout fonctionne, vérifions la suppression.