Guide de réalisation du projet

1. lisez le Cahier des charges de l’application;
2. gardez un marque-page sur ce cahier des charges, pour vous y référer au fur et à mesure de votre avancement.

Choisissez maintenant le domaine fonctionnel sur lequel vous souhaitez travailler (par exemple : « passionnés de guitare »).

Vous pouvez ainsi définir dès maintenant la nomenclature des classes du modèle de données de votre application. Ainsi, en reprenant l’exemple d’une application pour une communauté de passionnés de guitare (ou resp. de collectionneurs de cartes Pokémon), vous pouvez définir la nomenclature spécifique à votre projet :

Notez ces éléments dans un fichier de documentation que vous compléterez au fur et à mesure de l’avancement du projet. Nommez ce fichier README.txt (vous pouvez utiliser une syntaxe textuelle comme MarkDown ou org-mode du moment que c’est lisible sous forme de texte brut, et donc potentiellement gérable dans Git).

Vous n’avez plus qu’à vous lancer. Choisissez maintenant un nom de code pour votre projet (par exemple : « MyGuitars »).

1. Créez un nouveau répertoire pour y sauvegarder le travail sur votre projet, par exemple dans ~/CSC4101/projet/ :

   mkdir $HOME/CSC4101/projet/
   

Récupérez une copie du squelette d’application Symfony, pour initier le projet, en fonction de votre choix de nom de code :

cd $HOME/CSC4101/projet/
symfony new [nom-code] --version="6.3.*" --webapp

où [nom-code] est à adapter (par exemple symfony new myguitars --version="6.3.*" --webapp).

Un projet Symfony est créé dans le répertoire $HOME/CSC4101/projet/[nom-code]/, dans lequel vous allez travailler pour la suite.

Chargez ensuite le code du projet dans votre IDE.

Testez le lancement de l’application avec symfony server:start comme déjà rencontré pour l’application de démo, dans la validation des opérations d’installation de votre environnement BYOD.

À partir de maintenant, nous vous incitons à vous appuyer sur le référentiel Git (local) qui a été créé par la commande symfony new. Cela va vous permettre de gérer le code de votre projet en utilisant Git, soit en ligne de commande, soit via l’IDE.

Dans un premier temps, quelques git add suffiront, au fil des modifications.

La méthodologie que nous vous conseillons d’adopter est :

1. ajout au modèle de données de quelques entités fortement liées (sans être exhaustif sur leurs propriétés)
2. ajout de données de test minimales à charger en base de données
3. test du fonctionnement sur des manipulations basiques, avec l’ajout du tableau de bord d’administration EasyAdmin

Dans les séquences de travail suivantes vous pourrez continuer l’ajout de nouvelles entités du modèle, en suivant ces étapes, et en ajoutant les fonctions dédiées, une fois qu’on aura introduit les concepts et technos correspondantes :

1. réalisation de premières interfaces de consultation de ces données
2. raffinement des propriétés à gérer pour ces premières entités
3. itération pour d’autres entités, en ajoutant au fil de l’eau des associations entre entités anciennes et nouvelles

Vous aurez besoin de nombreuses entités dans le modèle des données de l’application, qui serviront à gérer les différentes fonctions, mais on ne va pas les ajouter toutes dès maintenant.

L’analyse du cahier des charges peut nous amener à dégager un ordre pour réaliser la mise en œuvre de façon itérative, afin de travailler et tester de façon progressive :

1. première liste d’entités pour débuter le noyau de l’application :
   • [inventaire]
   • [objet]

2. dans un second temps, on pourra ajouter, les entités restantes, pour lesquelles on a documenté des sections spécifiques du présent guide :

   • [galerie] (cf. « Ajout de l’entité [galerie] au modèle des données » à effectuer dans quelques temps)
   • membre (cf. « Ajout au modèle de données de l’entité membre… »)

   Respectez la chronologie indiquée par l’ordre des sections du guide: n’ajoutez les [galeries] qu’une fois que vous aurez réalisé les premières pages de consultation avec les gabarits pour [inventaire] et [objet].

Vous utiliserez les assistants de génération de code de Symfony pour générer le modèle pour Doctrine.

Avant de vous lancer dans le code, précisez (sur papier, dans un README, …) les propriétés que vous souhaitez utiliser pour ces premières entités, en vous aidant de l’exemple suivant :

Pour mémoire les étapes suivantes sont nécessaires pour l’ajout d’une nouvelle entité :

1. définir dans le code des classes PHP des attributs Doctrine (ORM\...) gérant la persistence de l’entité en base de données
2. re-générer la base de données de tests de l’environnement de développement en fonction des modifications que vous avez faites sur votre code

Avant de pratiquer, rappelons l’utilité et le principe de fonctionnement des différents outils qu’on utilisera, vus dans les deux premières séances de TP.

Configurez, dans le fichier .env la base de données, afin d’utiliser SQLite. La procédure pour ce faire a été vue en TP 1.

Pour cela, il faut ajouter le module doctrine/doctrine-fixtures-bundle dans le projet :

symfony composer require --dev orm-fixtures

Créez maintenant, de façon itérative, les premières entités, et leurs données de tests, en exécutant à chaque incrément les opérations suivantes :

1. Ajout de l’entité (par ex. [inventaire]) avec ses propriétés mono-valuées minimales :
   1. Appel à make:entity pour générer le nouveau code PHP
   2. Application des changements sur le schéma de la base
   3. Ajout dans les Fixtures du code de chargement de données de tests minimales
   4. Chargement des nouvelles données de tests pour cette entité (ça fonctionne !)

2. Ajout de l’entité suivante (par ex. [objet]) avec ses propriétés mono-valuées minimales :

   … (mêmes étapes que pour [inventaire])…

3. Ajout de l’association OneToMany entre les deux entités précédentes :

   … mêmes étapes, globalement, sauf qu’on rappelle make:entity sur l’entité [inventaire] existante pour la modifier, avec une propriétés multi-valuée de type relation (OneToMany), et qu’on gère les Fixtures avec des références (cf. ci-dessus) …

Une fois les premières entités [inventaire] et [objet] ajoutées, avec leur association OneToMany fonctionnelle, vous pouvez passer à l’étape suivante, pour ajouter un tableau de bord Web.

Vous continuerez l’ajout d’autres entités plus tard, en revenant à cette étape, incrément par incrément.

Enfin, bien plus tard, quand les pages Web, formulaires et autres choses à faire seront terminées, vous fignolerez le modèle de données en réutilisant make:entity pour ajouter les propriétés non-essentielles mais qui rendent le modèle de données réaliste. Et vous ajouterez donc dans la foulée les données de tests dans les Fixtures.

Pour cela, déroulez les instructions suivantes (en vous référant à la documentation https://symfony.com/bundles/EasyAdminBundle/current/index.html pour plus de détails) :

1. ajout du bundle EasyAdmin au projet, avec Composer :

   cd $HOME/CSC4101/projet/[nom-code]
   symfony composer req admin
   

2. création du controleur du tableau de bord d’administration src/Controller/Admin/DashboardController.php :

   symfony console make:admin:dashboard
   

3. Lancez le serveur Web de l’environnement de développement Symfony :

   symfony server:start
   

4. Testez dans le navigateur qu’une page « Welcome to EasyAdmin 4 » s’affiche bien sur l’URL /admin (sur http://locahost:8000/admin par exemple).

Vous allez ajouter au tableau de bord d’administration un premier contrôleur « CRUD » d’EasyAdmin qui servira à afficher et modifier les entités [inventaire].

1. création du contrôleur de gestion CRUD des [inventaire] src/Controller/Admin/[Inventaire]CrudController.php :

   symfony console make:admin:crud
   

2. réalisez ensuite le « câblage » de [Inventaire]CrudController dans l’affichage de la page principale (suivez les instructions données par la page /admin).

   Vous pouvez vous inspirer du code des classes de src/Controller/Admin/ dans ToDo pour voir comment contourner certaines difficultés.

   Ne jonglez pas trop avec toutes les customisations de configureFields() : pour l’instant on souhaite juste un affichage basique. Vous améliorerez les détails plus tard.

3. Testez que cela fonctionne et que les modifications sont possibles en base de données pour des [inventaires].

De la même façon, ajoutez ensuite au tableau de bord d’administration, le second contrôleur CRUD, pour l’entité [objet].

Si vous testez le fonctionnement de l’ajout d’objets, vous allez vite constater qu’il n’est pas possible de créer des objets isolés, en-dehors d’un inventaire (en tout cas si la référence entre objet et inventaire a été déclaré comme devant être non-nulle.

Vous allez donc ajouter la gestion de la référence à l’[inventaire] dans le contrôleur CRUD de l’[objet], pour cette association ManyToOne. Le principe consiste à ajouter, dans les champs du [Objet]CrudController d’EasyAdmin, un champ de sélection de type AssociationField, qui affichera alors l’entité [inventaire] liée :

class [Objet]CrudController extends AbstractCrudController
{

    // ...

    public function configureFields(string $pageName): iterable
    {
        return [
            //IdField::new('id'),
            TextField::new('description'),
            AssociationField::new('[inventaire]')
        ];
    }

}

Une fois ajouté ce champ AssociationField via la méthode configureFields() de [Objet]CrudController, on peut tester l’ajout d’un nouvel objet, mais aboutit à une erreur indiquant qu’il n’y a pas de méthode pour convertir [inventaire] en chaîne de caractères (« Object of class App\Entity\[Inventaire] could not be converted to string »).

Il suffit de corriger cela en ajoutant une méthode __toString() dans [inventaire].

Une fois que ça fonctionne, on s’aperçoit qu’EasyAdmin affiche bien une nouvelle colonne dans la liste des [objets], qui affiche leurs [inventaires].

Vous allez générer le code des premières classes contrôleurs Symfony pour mettre en place la consultation des premières entités, comme par exemple :

• la consultation d’une liste d’[objets] dans un [inventaire] particulier;
• la consultation d’une fiche d’un [objet] particulier.

Les pages et les routes gérées par ces contrôleurs concerneront la partie « front-office » de l’application (alors qu’EasyAdmin gère le back-office). C’est à dire celle utilisée par les membres de la communauté hébergée sur le site.

Une fois le code du contrôleur généré, vous enchainerez sur la conception du contenu des pages, dans les premiers gabarits (quand vous aurez appris Twig et HTML).

Quand vous maîtriserez l’ensemble de ces technologies, le processus sera le même pour l’ajout de chacune des pages relatives à la consultation des autres entités du site.

Nous verrons un peu plus tard qu’on pourra aussi utiliser un autre générateur de code (make:crud), qui permettra de créer le squelette de classes Controleur supportant des interactions CRUD. Cela augmentera encore plus notre productivité, mais il faut d’abord qu’on ait expérimenté le fonctionnement des controleurs, en consultation seulement.

Chaque chose en son temps : suivez le rythme suggéré dans ce guide, et vous devriez arriver lentement mais sûrement à un projet qui évoluera d’abord doucement, puis plus rapidement au fil du temps.

Pour l’instant, on va afficher deux pages permettant à un membre de retrouver :

• une liste de ses [inventaires] ;
• la consultation d’un [inventaire] particulier.

Attention aux nomenclatures classiques en orienté objet : les noms de classes commencent par des majuscules, avec un jeu de CamelCase en cas de juxtaposition de plusieurs mots.

Comme d’habitude, vous pouvez vous inspirer utilement du code que vous avez étudié sur l’application ToDo en TP.

1. Utilisez l’assistant make:controller pour générer le code d’une classe contrôleur, dont le nom lui est passé en argument :

   symfony console make:controller [Inventaire]Controller
   

   adaptez au nom de votre classe [inventaire] particulière, par exemple : symfony console make:controller RackController pour consulter les racks de guitares que gère chaque membre.

2. Consultez dans l’IDE le code de la classe qui a été ajoutée dans le fichier généré : src/Controller/[Inventaire]Controller.php.

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

   symfony console debug:router
   

   Comme vous pouvez le voir, l’assistant make:controller se base sur le nom de la classe contrôleur qu’on lui a donné en argument, pour en extraire un chemin d’URLs. Pour cela il le découpe en mots, en analysant les séquences de lettres commençant par une capitale.

   Notez sur quelle URL on peut trouver la page servie par le contrôleur qu’on vient d’ajouter :

   symfony console debug:router --show-controllers
   

4. lancez le serveur Web :

   symfony server:start
   

5. Testez l’URL http://127.0.0.1:8000 sur laquelle le serveur s’est lancé.

   Vous devez voir apparaître un message de Symfony, qui affiche « Your application is now ready ».

6. Testez l’URL servie par le nouveau contrôleur. Vous obtenez une page par défaut « Hello [Inventaire]Controller! »

   Succès ! \o/

On va adapter le code généré par l’assistant, pour mettre en œuvre un affichage rudimentaire de la liste des [inventaires] présents dans la base de données, lorsqu’on consulte la route « / » de notre serveur Web.

Vous allez donc modifier la méthode correspondante de la classe controleur. Examinez à quelle méthode correspond cette route (par exemple dans un autre onglet du terminal lancé depuis le même répertoire, pour ne pas interrompre le serveur HTTP) :

symfony console debug:router --show-controllers

Le chargement depuis la base de données ne devrait pas vous sembler très complexe à ajouter : on procède de la même façon que pour l’interface « console » des commandes étudiées précédemment, en faisant appel à Doctrine pour le chargement des données, en s’inspirant fortement du code présent dans ToDo.

Nous devons donc générer le contenu une page HTML à transmettre dans la réponse HTTP, mais nous n’avons pas encore étudié le langage HTML en détails.

Voici donc quelques éléments pour maquetter quelque chose qui y ressemble. Inspirez-vous de ce qui est fait dans le code de ToDo (dans listAction() dans src/Controller/TodoController.php), pour obtenir quelque chose du genre :

<html>
  <body>Liste des [inventaires] :
    <ul>
      <li>...premier [inventaire]...</li>
      ....
    </ul>
  </body>
</html>

Ce code HTML n’est pas idéal, mais il fonctionne à peu près, suffisamment pour que votre navigateur affiche la liste des [inventaires]. On travaillera sur la présentation ultérieurement.

Continuons avec d’autres pages gérées par le même controleur.

Vous allez ajouter une nouvelle méthode au contrôleur qui permettra la consultation via une route /[inventaire]/{id} :

/**
 * Show a [inventaire]
 *
 * @param Integer $id (note that the id must be an integer)
 */
#[Route('/[inventaire]/{id}', name: '[inventaire]_show', requirements: ['id' => '\d+'])]
public function show(ManagerRegistry $doctrine, $id)
{
        $[inventaire]Repo = $doctrine->getRepository([Inventaire]::class);
        $[inventaire] = $[inventaire]Repo->find($id);

        if (!$[inventaire]) {
                throw $this->createNotFoundException('The [inventaire] does not exist');
        }

        $res = '...';
        //...

        $res .= '<p/><a href="' . $this->generateUrl('[inventaire]_index') . '">Back</a>';

        return new Response('<html><body>'. $res . '</body></html>');
}

Modifiez ce code, notamment la valeur prise par $res, afin d’essayer de produire le contenu à afficher avec du code HTML (toujours en vous inspirant du code de ToDo). Attention à ne pas laisser des crochets « [...] », en copiant-collant, et à respecter la syntaxe PHP, les noms de vos classes, etc.

Testez l’accès à l’URL http://localhost:8000/[inventaire]/1234.

L’argument et $id de la méthode show() est extrait automatiquement de la route, conformément à la spécification l’attribut Route qui a été placé immédiatement au-dessus de la définition de la méthode.

Notez que lorsque tout se passe bien, on renvoit un objet Response. Quand une erreur survient, on peut interrompre les traitements en déclenchant l’apparition d’une exception avec throw, ce qui aboutit au renvoi au client du code de réponse HTTP correspondant.

Si tout ça ne fonctionne pas… c’est peut-être juste qu’il manque des données de test dans votre projet (cf. DataFixtures), ou bien qu’il y a un bug.

Ajoutez, dans le code de fabrication de la liste des [inventaires], la génération des liens permettant d’accéder à la consultation des fiches de chaque [inventaire]. Cela fait le lien entre les deux étapes précédentes.

On peut ajouter une balise HTML <a href="...">...</a> pour créer un tel lien, du style :

Liste des [inventaires] :
...
   <li><a href="/[inventaire]/42">un [inventaire] (42)</a></li>

Vous utiliserez la méthode generateUrl() du contrôleur, qui sait générer une URL conforme à une définition de Route(...).

Ainsi, pour la route [inventaire]_show définie par #[Route('/[inventaire]/{id}', name: '[inventaire]_show')], qui utilise un attribut pour générer l’URL, on passera la valeur correspondante via :

$url = $this->generateUrl(
    '[inventaire]_show',
    ['id' => $[inventaire]->getId()]);

Testez que cela fonctionne.

Pour voir la liste des objets en question, il faut aller dans le menu (« … ») et sélectionner « Edit ». À ce stade, il faut régler éventuellement un problème récurrent de représentations des classes sous forme textuelle. Une fois que ce problème est réglé, la page de modification de l’[inventaire] affiche bien la liste des [objets] qu’il contient.

On aimerait bien consulter également la liste des [objets] dans une page d’affichage d’une « fiche » pour chaque inventaire, avec des liens cliquables… mais il est encore un peu tôt pour faire cela.

Pour l’instant, on va se contenter de cette page de modification, et on reviendra vers l’affichage d’une page de « fiche » pour chaque inventaire, quand on aura étudié les gabarits Twig.

Vous ajoutez donc maintenant un premier gabarit pour la consultation des propriétés d’un [inventaire]. Inspirez-vous de la façon dont on a ajouté l’affichage des propriété d’une tâche dans la page de consultation des tâches dans l’application Todo, dans le TP 5.

On peut faire cela simplement, par exemple en construisant un tableau HTML avec une ligne par propriété de l’[inventaire], dans le gabarit templates/[inventaire]/show.html.twig= :

{# ... #} 
  {% block body %}
      <h1>[Inventaire]</h1>

         {% dump [inventaire] %}

      <table class="table">
          <tbody>
              <tr>
                  <th>Id</th>
                  <td>{{ [inventaire].id }}</td>
              </tr>
              <tr>
                  <th>Propriété 1</th>
                  <td>{{ [inventaire].prop_1 }}</td>
              </tr>
              ...
          </tbody>
      </table>

      <a href="{{ path('[inventaire]_index') }}">back to list</a>

  {% endblock %} {# body #} 
{# ... #} 

Pour l’instant on n’affiche que les propriétés mono-valuées, et on verra un peu plus bas, l’ajout de l’affichage des [objets] de cet [inventaire].

Testez que cela fonctionne, et réglez les éventuels soucis de noms de routes à ajuster.

Au fur et à mesure de l’ajout des entités dans le modèle de données, vous réaliserez, une à la fois, l’ajout des pages correspondantes dans le front-office.

On va modifier les actions possibles sur une entité, dans EasyAdmin, pour passer de la liste des entités à l’affichage d’une seule entité.

Étonnament, EasyAdmin ne nous propose pas, par défaut, d’afficher une entité, bien qu’il nous permette de l’éditer ou de la supprimer…

On peut corriger ça en ajoutant la méthode suivante configureActions() à notre [Inventaire]CrudController (cf. https://symfony.com/bundles/EasyAdminBundle/current/actions.html)

class [Inventaire]CrudController extends AbstractCrudController
{
    //...

    public function configureActions(Actions $actions): Actions
    {

        return $actions
            ->add(Crud::PAGE_INDEX, Action::DETAIL)
        ;
    }

    //...

Cela permet d’obtenir un nouveau menu « Show » pour invoquer l’affichage d’une fiche d’[inventaire].

On peut ensuite customiser plus ou moins l’affichage des champs dans cette page (cf. « Customisation des affichages dans le tableau de bord » qui était une section optionnelle auparavant).

Maintenant qu’on sait afficher une « fiche » avec les détails d’un [inventaire] on va y afficher la liste des [objets] de cet inventaire, au lieu du champ donnant le nombre d’[objets]

Le principe consiste à configurer l’affichage de l’attribut contenant la collection des [objets] pour lui donner un élément de gabarit Twig spécifique, comme dans le code ci-dessous :

class [Inventaire]CrudController extends AbstractCrudController
{
      //...
          public function configureFields(string $pageName): iterable
          {
                  return [
                          IdField::new('id')->hideOnForm(),
                          TextField::new('description'),
                          AssociationField::new('[objets]')
                                  ->onlyOnDetail()
                                  ->setTemplatePath('admin/fields/[inventaire]_[objets].html.twig')

                  ];
          }

Ce code indique que notre attribut [Inventaire]::[objets] de type OneToMany dans le modèle de données, est affiché sous forme de champ AssociationField, et qu’on ne souhaite l’afficher que dans cette nouvelle page « DETAILS » (menu « Show »), et que l’affichage de la page va devoir prendre en compte un gabarit qui spécialise une partie de l’affichage de cette page.

En effet, on va créer dans notre projet, un fichier de gabarit Twig admin/fields/[inventaire]_[objets].html.twig qui contiendra quelque chose du type :

{# source: https://stackoverflow.com/a/65082524/1814910 #}
  <ul>
{% for [object] in field.value %}
  {%- set url = ea_url()
    .setController('App\\Controller\\Admin\\[Object]CrudController')
    .setAction('detail')
    .setEntityId([object].id)
  -%}
  <li>
  	<a href="{{ url }}">
        {{ [object] }}
  	</a>
  </li>
{% else %}
</ul>  
  <span class="badge badge-secondary">None</span>
  <ul>
{% endfor %}
  </ul>

Mettons les choses au point : vos profs n’ont pas trouvé ça tous seuls, et se sont inspirés de l’exemple donné par « Flash » (résident à Kyiv en Ukraine ?)… (nous aussi on utilise StackOverflow ;-)

Vous pouvez observer, via l’outil Twig de la barre d’outils Symfony la façon dont une page « DETAILS » est compilée à partir des gabarits de EasyAdmin. C’est très touffu et assez vertigineux… mais cela explique pourquoi EasyAdmin permet d’afficher, de base, autant de widgets graphiques sans avoir à coder en HTML dans des gabarits Twig.

Mais ici, il nous faut bien customiser cet affichage par défaut et ajouter nos propres bouts, en ne surchargeant que le morceau nécessaire.

Au lieu d’afficher le nombre d’éléments dans la collection des [objets] on va afficher une liste à puce <ul><li>...</li> ... </ul>, en itérant pour chaque [objet] de notre champ AssociationField (donc on itère sur les valeurs du champ : field.value). Il ne reste qu’à (vite dit) construire l’URL qui pointe vers l’affichage d’une page de detail pour un [objet]. Et cette URL, c’est celle de l’action detail du controleur EasyAdmin [Object]CrudController… et on passe à cette route la valeur de l’id de notre [objet]… simple à comprendre (?)… difficile à trouver (sur StackOverflow… ou dans la doc, mais nous ne l’avons pas trouvé dans la doc).

Le reste est cosmétique pour que ça soit joli dans l’affichage avec BootStrap que fait EasyAdmin.

Vous venez de voir ainsi un mécanisme qu’on pourra reproduire à loisir dans une backoffice EasyAdmin dès qu’on souhaitera customiser l’apparence.

Maintenant que vous savez le faire, vous pourrez dupliquer cela pour toutes les relations OneToMany nécessaires (sans en abuser non-plus), ou pour tout autre élément de customisation du backoffice.

Start Bootstrap propose différentes distributions de Bootstrap prêtes à l’emploi. Nous vous suggérons de partir de cette distribution, en suivant les étapes ci-après, mais vous pourriez également partir de la distribution « standard » de bootstrap disponible sur le site du projet.

L’avantage de Start Bootstrap est de proposer des « thèmes » prêts à l’emploi.

Pour ToDo, dans le TP 6, on a utilisé une distribution très basique : « StartBootstrap Bare ».

Pour le projet, nous vous suggérons de récupérer par exemple la variante de la distribution : « Shop Homepage », qui propose l’affichage de liste de « produits ».

Vous pourrez adapter la mise en forme ultérieurement selon vos goûts, en explorant d’autres variantes de mise en forme, de thèmes Bootstrap.

1. Récupérez la distribution Bootstrap Shop Homepage (par exemple avec wget en ligne de commande) :

   cd public
   wget https://github.com/startbootstrap/startbootstrap-shop-homepage/archive/gh-pages.zip
   unzip gh-pages.zip
   

   les ressources statiques ont été extraites dans public/startbootstrap-shop-homepage-gh-pages/

2. Configurez l’emplacement des ressources assets de Symfony pour pointer dans ce sous-répertoire. Modifiez config/packages/framework.yaml pour ajouter :

   framework:
     ...
       assets:
           base_path: '/startbootstrap-shop-homepage-gh-pages'
   

Bootstrap est prêt à être intégré dans les gabarits pour que le HTML l’utilise.

Pour ajouter BootStrap dans une page HTML, il faut que celle-ci charge les ressources statiques correspondant à ses feuilles de style CSS, et aux scripts JavaScript associés (dont ceux de la bibliothèque JQuery).

Vous allez ainsi devoir ajouter les en-têtes HTML « classiques » nécessaires dans votre gabarit de base, en indiquant les chemins des CSS via la macro asset() de Twig :

<!-- Core theme CSS (includes Bootstrap)-->
<link href="{{ asset('css/styles.css') }}" rel="stylesheet">

Vous ajouterez ensuite l’invocation des scripts Javascript, à la fin du contenu de la balise <body> du code HTML, également via la macro asset() de Twig :

<!-- Bootstrap core JS-->
<script src="https://cdn.jsdelivr.net/npm/bootstrap@5.2.3/dist/js/bootstrap.bundle.min.js"></script>
<!-- Core theme JS-->
<script src="{{ asset('js/scripts.js') }}"></script>

Pour construire ces éléments de gabarit, vous pouvez vous inspirer du contenu du fichier HTML d’exemple qui est fourni dans la distribution « Shop homepage », présent dans le répertoire public/startbootstrap-shop-homepage-gh-pages/index.html pour reprendre ces éléments HTML et les adapter pour Twig.

Au final, le code de base.html.twig ressemble à :

<!DOCTYPE html>
<html>
    <head>
        <meta charset="UTF-8">
        <title>{% block title %}Welcome!{% endblock %}</title>
        <link rel="icon" href="data:image/svg+xml,<svg xmlns=%22http://www.w3.org/2000/svg%22 viewBox=%220 0 128 128%22><text y=%221.2em%22 font-size=%2296%22>⚫️</text></svg>">

        {% block stylesheets %}
        <!-- Bootstrap icons-->
        <link href="https://cdn.jsdelivr.net/npm/bootstrap-icons@1.5.0/font/bootstrap-icons.css" rel="stylesheet" />
        <!-- Core theme CSS (includes Bootstrap)-->
        <link href="{{ asset('css/styles.css') }}" rel="stylesheet">
        {% endblock %} {# stylesheets #}

    </head>
    <body>

       {# ... #}

       {% block body %}

         {# ... #}

       {% endblock %}{# body #}
       {% block javascripts %}
       <!-- Bootstrap core JS-->
       <script src="https://cdn.jsdelivr.net/npm/bootstrap@5.2.3/dist/js/bootstrap.bundle.min.js"></script>
       <!-- Core theme JS-->
       <script src="{{ asset('js/scripts.js') }}"></script>
       {% endblock %} {# javascripts #}

    </body>
</html>

Si vous rechargez les pages de l’application, elles incluent désormais la mise en forme par défaut de BootStrap.

Une fois que votre front-office s’affiche bien avec le CSS de bootstrap, il se peut fort que votre backoffice ne s’affiche plus bien.

Pour corriger cela :

1. Modifiez la configuration des assets dans config/packages/framework.yaml pour régler celà :

   framework:
       ...
       assets:
           packages:
               bootstrap:
                   base_path: '/startbootstrap-bare-gh-pages'
   

2. Modifiez à son tour le gabarit de base de l’application (base.html.twig) pour changer les appels à asset() pour ajouter en argument le nom du paquetage qu’on vient d’ajouter dans la configuration ci-dessus (’bootstrap’), pour utiliser par exemple : asset('css/styles.css', 'bootstrap')
3. Invoquez la commande : symfony console assets:install

Normalement, l’ensemble des présentations fonctionnent correctement.

Pour intégrer le composant de fabrication de menus compatible BootStrap, qui a été observé pour l’application ToDo en TP 6, procédez aux étapes suivantes :

1. Créez le fichier de configuration config/packages/bootstrap_menu.yaml, en recopiant celui de l’application ToDo.

2. Installez le bundle correspondant :

   symfony composer require camurphy/bootstrap-menu-bundle
   

3. Ajoutez le code HTML pour le menu Bootstrap dans votre gabarit de base, pour insérer des menus dans les <nav> des pages de l’application.

   Inspirez-vous du code de public/startbootstrap-shop-homepage-gh-pages/index.html, pour l’ajouter dans un bloc Twig menu placé avant le bloc body, dans base.html.twig. Vous ne gardez que la partie englobante du <nav>, jusqu’au <ul> </ul>, qui ressemblera donc à :

   {# ... #}
   <body>
   
        {% block menu %}
        <!-- Navigation -->
           <nav class="navbar navbar-expand-lg navbar-light bg-light">
               <div class="container px-4 px-lg-5">
                   <a class="navbar-brand" href="{{ path('inventory_list') }}">My app</a>
                   <button class="navbar-toggler" type="button" data-bs-toggle="collapse" data-bs-target="#navbarSupportedContent" aria-controls="navbarSupportedContent" aria-expanded="false" aria-label="Toggle navigation"><span class="navbar-toggler-icon"></span></button>
                   <div class="collapse navbar-collapse" id="navbarSupportedContent">
                       <ul class="navbar-nav me-auto mb-2 mb-lg-0 ms-lg-4">
   
                       </ul>
                   </div>
               </div>
           </nav>
        {% endblock %}{# menu #}
   
       {% block body %}
   
         {# ... #}
   
       {% endblock %}{# body #}
   
   

4. Vous pouvez ensuite insérer l’utilisation de render_bootstrap_menu() dans le <ul> </ul>. Vous obtiendrez par exemple, dans base.html.twig quelque chose du style :

   {# ... #}
   <body>
   
        {% block menu %}
        <!-- Navigation -->
           <nav class="navbar navbar-expand-lg navbar-light bg-light">
               <div class="container px-4 px-lg-5">
                   <a class="navbar-brand" href="{{ path('inventory_list') }}">My app</a>
                   <button class="navbar-toggler" type="button" data-bs-toggle="collapse" data-bs-target="#navbarSupportedContent" aria-controls="navbarSupportedContent" aria-expanded="false" aria-label="Toggle navigation"><span class="navbar-toggler-icon"></span></button>
                   <div class="collapse navbar-collapse" id="navbarSupportedContent">
                       <ul class="navbar-nav me-auto mb-2 mb-lg-0 ms-lg-4">
                         {{ render_bootstrap_menu('main') }}
                       </ul>
                   </div>
               </div>
           </nav>
        {% endblock %}{# menu #}
   
       {% block body %}
   
         {# ... #}
   
       {% endblock %}{# body #}
   
   

5. Configurez enfin les menus à afficher, en ajoutant les routes correspondantes, dans config/packages/bootstrap_menu.yaml.

Suivez la documentation du README pour plus de détails sur son fonctionnement.

Pour l’instant, commencez avec un menu minimal, que vous pourrez enrichir au fur et à mesure de l’ajout de nouvelles fonctionnalités dans les contrôleurs de l’application.

Exécutez l’assistant Symfony make:crud, pour la classe [Galerie] du modèle de données

symfony console make:crud

Vous pouvez tester que si les formulaires gérant le CRUD fonctionnent bien, sur http://localhost:8000/[galerie]/

Poursuivez sur les étapes découvertes en TP 7, pour customiser un peu l’affichage dans les gabarits générés par l’assistant, afin d’avoir un affichage correct avec Bootstrap.

Vous pourrez améliorer encore cela après le TP 8, pour gérer l’affichage des messages flash.

Recopiez les méthodes et fichiers de création de [galerie] pour les ajouter dans le contrôleur d’inventaire :

• [Galerie]Controller::new() dans [Inventaire]Controller (en renommant les noms de variables, classes et chemins et noms de routes)
• templates/[galerie]/new.html.twig dans templates/[inventaire]/new.html.twig
• templates/[galerie]/_form.html.twig dans templates/[inventaire]/_form.html.twig
• src/Form/[Galerie]Type.php dans src/Form/[Inventaire]Type.php

On va ainsi définir un « point d’entrée » dans l’application, qui sera la consultation d’un Membre. Depuis la consultation d’un Membre, on aura accès à son ou ses [inventaires], et de là aux [objets], etc.

1. Ajoutez une classe Controleur pour l’entité Membre, avec make:controller

2. Ajoutez deux méthodes index() et show() pour afficher la liste des membres et la fiche de chaque membre, et le contenu des gabarits correspondants, comme on l’a fait auparavant pour d’autres entités

   Dans la fiche d’un membre, on affichera la liste de ses [inventaires]. Par exemple, on obtiendrait ceci dans le gabarit templates/member/show.html.twig :

   {% for [inventory] in member.[inventories] %}
     <li><a href="{{ path('app_inventory_show', {'id' : inventory.id}) }}">{{ inventory }}</a></li>
   {% endfor %}
   

3. Supprimez l’accès à la consultation des inventaires

   L’affichage de la liste des [inventaires] devra être restreinte, pour ne pas afficher tous les [inventaires] de la base de données, mais seulement le ou les [inventaires] du membre.

   On pourra ainsi désactiver l’affichage de la liste des inventaires (route app_[inventaire]_index). Plus tard, une fois qu’on aura géré l’authentification, on pourra la réactiver pour contextualiser le chargement de la liste des [inventaires] en le restreignant aux données du membre particulier lié à l’utilisateur connecté.

Pour accéder à la page de consultation d’un inventaire, on utilisera alors des liens placés dans la page de consultation du membre. Le routage d’accès à la liste des [inventaires] va donc changer pour prendre en argument l’identifiant du membre courant.

On ajustera également la création d’un nouvel inventaire, qui dépendra alors du membre courant.

Dans templates/member/show.html.twig, on ajoutera donc un lien :

<a href="{{ path('app_inventory_new', {'id': member.id}) }}">add new inventory</a>

La route app_inventory_new changera donc pour prendre en compte ce nouveau contexte où on passe l’identifiant du membre en argument. Extrait de src/Controller/InventoryController.php :

#[Route('/[inventaire]/new/{id}', name: 'app_[inventory]_new', methods: ['GET', 'POST'])]
public function new(Request $request, [Inventory]Repository $inventoryRepository, Member $member): Response
{
        $inventory = new Inventory();
        $inventory->setOwner($member);

On a modifié la méthode new() pour ajouter le chargement du membre passé dans l’argument de la route, et initialiser le nouvel [inventaire] comme appartenant à ce membre.

On peut alors ajouter une customisation du formulaire de création pour ne pas autoriser la modification de l’attribut membre d’un [inventaire]. Ainsi dans la classe gérant le formulaire src/Form/InventoryType.php :

class InventoryType extends AbstractType
{
        public function buildForm(FormBuilderInterface $builder, array $options): void
        {
                $builder
                        ->add('description')
                        ->add('owner', null, [
                                'disabled'   => true,
                        ])
                ;
        }

Ici, l’attribut faisant le lien, owner, est désactivé. Il apparaît dans le formulaire de création de l’[inventaire], mais il est grisé (et renseigné à la bonne valeur, puisqu’on a appliqué le setter à l’initialisation de l’objet en mémoire).

On peut donc maintenant appliquer le même genre de modifications la consultation et la création des [objets] à partir de la consultation d’un [inventaire] pour garder le contexte courant (Membre -> [inventaire] -> [objet]), plutôt que de créer les entités « en vrac ».

Tout d’abord, on doit modifier la création d’une nouvelle [galerie] comme on l’a fait pour les [inventaires] pour qu’elle soit contextualisée à partir du membre (cf. étape précédente).

Ensuite, on peut judicieusement modifier l’affichage de la liste des [galeries], pour ne charger que les galeries déclarées comme publiques. Il suffit pour cela de replacer le findAll() appelé sur le [Galerie]Repository, en findBy(['published' => true]).

Enfin, modifions le formulaire de modification de [galerie]. Il s’agit d’agir dans la classe gestionnaire du formulaire de modification d’une [galerie], [Galerie]Type (dans src/Form/[Galerie]Type.php), pour obtenir quelque chose du type :

class [Galerie]Type extends AbstractType
{
        public function buildForm(FormBuilderInterface $builder, array $options): void
        {
                //dump($options);
                $[galerie] = $options['data'] ?? null;
                $member = $[galerie]->getCreator();

                $builder
                        ->add('description')
                        ->add('published')
                        ->add('creator', null, [
                                'disabled'   => true,
                        ])
                        ->add('[objets]', null, [
                                'query_builder' => function ([Objet]Repository $er) use ($member) {
                                                return $er->createQueryBuilder('o')
                                                ->leftJoin('o.[inventaire]', 'i')
                                                ->andWhere('i.owner = :member')
                                                ->setParameter('member', $member)
                                                ;
                                        }
                                ])
                ;
        }

Le principe est de construire le champ de formulaire [objets], qui gère la modification de la collection des [objets] apparaissant dans la [galerie], en spécifiant une méthode particulière de chargement des données, au lieu de charger tous les [objets] de la base. On utilise donc l’option query_builder des formulaires pour lui passer une fonction (anonyme) qui va construire la requête en base.

La requête doit faire une jointure avec les [inventaires] du même membre. Le membre de la [galerie] est récupérable à partir des données du formulaire, présentes dans $options['data'] (une instance de la classe [Galerie]; en cas de doute, utilisez dump() pour vérifier). Une « astuce » à bien noter est l’utilisation du use ($member) dans la définition de la fonction anonyme, qui permet de transférer une copie du membre à la fonction, pour qu’elle s’en serve dans le WHERE.

Vous devrez ajuster les noms d’attributs, d’entités et de classes pour coller à votre modèle de données particulier.

Vérifiez dans la barre d’outils Symfony, avec l’icône et la section « Forms », les détails des options du formulaire du sous-formulaire du champ « [objets] » pour voir si le « query builder » est bien défini, et dans l’onglet Doctrine, la requête transmise à la base de données.

En modifiant les options du constructeur de formulaire pour le champ de l’association manyToMany, on obtient alors un code du style :

//use Symfony\Bridge\Doctrine\Form\Type\EntityType;

class [Galerie]Type extends AbstractType
{
    //...
    public function buildForm(FormBuilderInterface $builder, array $options): void
    {
        $builder
            //...
            // par défaut, si on ne spécifie pas le type de champ de formulaire
            // c'est un EntityType
            //->add('[objets]')
            ->add('[objets]',
                  //EntityType::class,
                  null,
                  // options :
                  [
                      // avec 'by_reference' => false, sauvegarde les modifications
                      'by_reference' => false,
                      // classe pas obligatoire
                      //'class' => [Object]::class,
                      // permet sélection multiple
                      'multiple' => true,
                      // affiche sous forme de checkboxes
                      'expanded' => true
                  ]
            )
            ;
        ;
    }
}

Ça permet de gérer les objets au sein du formulaire de modification de la galerie… Mais plutôt cryptique si on n’a pas tous les commentaire !

Dans une « vraie application » on distinguera la page de modification des propriétés d’une [galerie], de la page d’ajout du contenu de la galerie… ou du moins, c’est géré dans du code différent des mécanismes de formulaires Symfony « basiques » tels qu’ils sont générés par make:crud.

Des solutions sont possibles, avec les formulaires avancés, des dialogues, un enchaînement de pages, du Javascript… mais pas les formulaires CRUD simples de Symfony. Ça demanderait beaucoup plus de travail, donc nous n’avons pas demandé cela dans le projet.

On est donc ici en limite de ce qu’on peut aborder en détails dans le cours (faute de temps), donc de ce qu’on peut attendre dans les projets.

Si ça marche, tant mieux… sinon, ce n’est pas pénalisable. Vous avez fait de votre mieux, avec ce qu’on a étudié.

Vous pouvez reprendre le code de chargement de données de tests des utilisateurs fourni en TP 9 pour ajouter la génération des utilisateurs dans les Data Fixtures.

Pour intégrer les données de tests des utilisateurs avec le reste de la base de données, on est alors potentiellement confronté à l’ordre de chargement. Pour s’assurer que les données sont chargées dans le bon ordre, on peut définir les fixtures d’AppFixtures comme dépendantes de celles de UserFixtures :

// ...
use Doctrine\Common\DataFixtures\DependentFixtureInterface;


class AppFixtures extends Fixture implements DependentFixtureInterface
{

        // ...

        public function getDependencies()
        {
                return [
                        UserFixtures::class,
                ];
        }

Ainsi, on pourra charger d’abord les instances de User, puis s’y relier à la création des Membres associés, en chargeant les User par leur email, avec findOneByEmail() :

foreach (self::MembersDataGenerator() as [$name, $useremail] ) {
        $member = new Member();
        if ($useremail) {
                $user = $manager->getRepository(User::class)->findOneByEmail($useremail);
                $member->setUser($user);
        }
        $member->setName($name);
        $manager->persist($member);
}
$manager->flush();

On pourra ainsi restreindre l’accès aux contrôleurs [Objet]Controller, [Inventaire]Controller, MemberController,… uniquement aux utilisateurs authentifiés sur le site. Seul le controlleur des [Galeries] n’est pas concerné, car il devra, lui, être accessible à tous les visiteurs du site, même non-authentifiés.

Exemple d’annotation dans une classe contrôleur, nécessitant un login pour tout accès aux routes dont le chemin est préfixé par /[objet] :

#[Route('/[objet]')]
#[IsGranted('IS_AUTHENTICATED_FULLY')]
class [Objet]Controller extends AbstractController
{

La consultation des entités via les méthodes show() des contrôleurs CRUD doit être réservée aux seuls propriétaires de ces données, ou aux administrateurs. Ainsi, on peut refuser l’accès avec un code du type :

$hasAccess = $this->isGranted('ROLE_ADMIN') ||
    ($this->getUser()->getMember() == $[inventaire]->getOwner());
if(! $hasAccess) {
    throw $this->createAccessDeniedException("You cannot access another member's [inventory]!");
}

Les méthodes des contrôleurs gérant les formulaires de CRUD (new(), edit() et delete() doivent être adaptés également, pour s’assurer que l’utilisateur authentifié peut légitimement les invoquer, car il est propriétaire des données.

Certaines devront être réservées aux administrateurs, ou simplement supprimées, car on imaginera un autre mécanisme pour la désinscription d’un membre, que d’appeler la méthode delete() du contrôleur MemberController dans formulaire de suppression tel que généré par make:crud. Dans tous les cas, le back-office sera là également en cas de besoin.

Pour les [galeries] non publiées, on doit restreindre l’accès aux utilisateur propriétaires de ces [galeries] (ou aux administrateurs), mais comme l’accès n’est pas contrôlé globalement à toutes les routes de ce contrôleur, contrairement aux autres, il faudrait mettre en place un code un peu plus fin, du type :

#[Route('/{id}', name: 'app_[galerie]_show', methods: ['GET'])]
public function show([Galerie] $[galerie]): Response
{
        $hasAccess = false;
        if($this->isGranted('ROLE_ADMIN') || $[galerie]->isPublished()) {
                $hasAccess = true;
        }
        else {
                $user = $this->getUser();
                if( $user ) {
                        $member = $user->getMember();
                        if ( $member &&  ($member == $[galerie]->getCreator()) ) {
                                $hasAccess = true;
                        }
                }
        }
        if(! $hasAccess) {
                throw $this->createAccessDeniedException("You cannot access the requested resource!");
        }
        return $this->render('[galerie]/show.html.twig', [
                '[galerie]' => $[galerie],
        ]);
}

Notez que ce code est très verbeux, mais compliqué à écrire car on n’est pas sûr qu’un utilisateur soit connecté, ni qu’il ait un membre associé, et on doit donc progresser en testant l’existance des instances avant d’appeler leur méthodes.

En PHP 8, on pourrait raccourcir en utilisant l’opérateur nullsafe qui permet d’éviter ce genre de tests et d’écrire quelque chose comme $this->getUser()?->getMember()?->....

De façon similaire, on va retoucher le code de l’accès aux [objets] dans une [galerie] non publique, si elle appartient à l’utilisateur courant :

public function [objet]Show([Galerie] $[galerie], [Objet] $[objet]): Response
{
        if(! $[galerie]->get[Objets]()->contains($[objet])) {
                throw $this->createNotFoundException("Couldn't find such a [objet] in this [galerie]!");
        }

        $hasAccess = false;
        if($this->isGranted('ROLE_ADMIN') || $[galerie]->isPublished()) {
                $hasAccess = true;
        }
        else {
                $user = $this->getUser();
                  if( $user ) {
                          $member = $user->getMember();
                          if ( $member &&  ($member == $[galerie]->getCreator()) ) {
                                  $hasAccess = true;
                          }
                  }
        }
        if(! $hasAccess) {
                throw $this->createAccessDeniedException("You cannot access the requested ressource!");
        }

        return $this->render('[galerie]/[objet]_show.html.twig', [
                '[objet]' => $[objet],
                  '[galerie]' => $[galerie]
          ]);
}

Au final, l’algorithme est très complexe, et pourrait probablement receler beaucoup de bugs.

Seules les [galeries] publiques sont visibles par tous les utilisateurs.

Les [galeries] non publiques sont visibles uniquement par leur propriétaire.

L’administrateur peut tout consulter.

Exemple de code de sélection des [galeries] privées d’un utilisateur authentifié (ayant un membre associé) :

$private[Galeries] = array();
$user = $this->getUser();
if($user) {
        $member = $user->getMember();
        $private[Galeries] = $[galerie]Repository->findBy(
                [
                      'published' => false,
                      'creator' => $member
                ]);
}

On peut donc modifier le code des méthodes de chargement en utilisant un code du style (dans [Objet]Controller) :

#[Route('/', name: 'app_[objet]_index', methods: ['GET'])]
public function index([Objet]Repository $[objet]Repository): Response
{
        if ($this->isGranted('ROLE_ADMIN')) {
                $[objets] = $[objet]Repository->findAll();
        }
        else {
                $member = $this->getUser()->getMember();
                $[objets] = $[objet]Repository->findMember[Objets]($member);
        }

On va donc s’appuyer sur une méthode ajoutée au Repository de l’entité [objet] pour charger les données d’un membre.

Par exemple, ici, dans src/Repository/[Objet]Repository.php :

/**
 * @return [Objet][] Returns an array of [Objet] objects for a member
 */
 public function findMember[Objets](Member $member): array
{
        return $this->createQueryBuilder('o')
                 ->leftJoin('o.[inventory]', 'i')
                 ->andWhere('i.owner = :member')
                 ->setParameter('member', $member)
                 ->getQuery()
                 ->getResult()
         ;
}

Cette méthode va charger uniquement les [objets] du membre passé en argument.

Pour charger le ou les [inventaires] d’un membre, par contre, c’est plus simple, car on a déjà un lien entre membre et [inventaire] dans le modèle de données, donc pas besoin d’ajouter une méthode de chargement supplémentaire dans le repository. On utilise directement $[inventaires] = $member->get[Inventaires]().

Lorsqu’un [inventaire] est supprimé, on va décider qu’on ne doit pas garder en base de donnée les [objets] qu’il contenait. Dans une application réelle, on pourrait procéder différemment, par exemple en proposant à l’utilisateur de transférer ses fiches d’[objets] dans une « poubelle », permettant éventuellement de les récupérer pour les remettre dans un autre inventaire (ou de gérer le don à un autre utilisateur, etc.)

Ici, pour supprimer les [objets] contenus, on va modifier le comportement de la méthode remove() du repository [Inventaire]Repository, qui est appelée par le gestionnaire de la suppression dans le contrôleur. On codera quelque chose du style :

public function remove([Inventaire] $entity, bool $flush = false): void
{
        $[objet]Repository = $this->getEntityManager()->getRepository([Objet]::class);

        // clean the [objets] properly
        $[objets] = $entity->get[Objets]();
        foreach($[objets] as $[objet]) {
                $[objet]Repository->remove($[objet], $flush);
        }
        $this->getEntityManager()->remove($entity);

        if ($flush) {
                $this->getEntityManager()->flush();
        }
}

On appelle, de façon « transitive », la méthode remove() sur le repository des [objets].

Ensuite, de façon similaire on va modifier cette même méthode pour défaire proprement les associations ManyToMany de l’[objet] supprimé (ci-dessous).

Nos [objets] sont associés à différentes entités [galeries] par des associations ManyToMany dans le modèle de données.

Si on n’ajoute pas la suppression effective, il y a des chances que la base de données contienne de nombreuses scories pour des liens référençant des [objets] qui auront été supprimés.

Pour s’en aperçevoir, on peut supprimer tous les [inventaires] et donc tous leurs [objets] (cf. ci-dessus), et faire des requêtes SQL. On voit alors qu’il reste de nombreux couples dans les tables d’association des ManyToMany, qui référencent encore les [object]_id supprimés.

On n’aura probablement pas à constater des bugs pour autant (d’où le fait que cette étape soit optionnelle), car les jointures faites par Doctrine au chargement, par exemple, ne feront pas apparaître ces liens manquant, ne prenant en compte que les données existantes dans la table d’[objet]. Néanmoins, on court un risque de saturation inutile de la base de données.

Pour faire le ménage proprement, il convient de modifier la méthode remove() de l’[Objet]Repository, un peu comme pour le cas précédent.

Première étape : supprimer l’association entre l’[objet] et les [galeries] dans lesquelles il était présent :

public function remove([Objet] $entity, bool $flush = false): void
{
        $[galerie]Repository = $this->getEntityManager()->getRepository([Galerie]::class);

        // get rid of the ManyToMany relation with [galeries]
        $[galeries] = $[galerie]Repository->find[Objet][Galeries]($entity);   
        foreach($[galerie]s as $[galerie]) {
                $[galerie]->remove[Objet]($entity);
                $this->getEntityManager()->persist($[galerie]);
        }
        if ($flush) {
                  $this->getEntityManager()->flush();
        }
        //...

Si nous avons une méthode permettant de supprimer un [objet] d’une [galerie], [Galerie]::remove[Objet](), il nous manquait encore le moyen de charger les galeries référençant un [objet]. C’est le rôle de la méthode de chargement ajoutée au [Galerie]Repository, find[Objet][Galeries]() :

/**
 * @return [Galerie][] Returns an array of [Galerie] objects
 */
 public function find[Objet][Galeries]([Objet] $[objet]): array
{
    return $this->createQueryBuilder('g')
        ->leftJoin('g.[objets]', 'o')
        ->andWhere('o = :[objet]')
        ->setParameter('[objet]', $[objet])
        ->getQuery()
        ->getResult()
    ;
}

Cette méthode renvoit les [galeries] qui référencent un [objet] passé en argument.

Une fois qu’on a cette méthode, on appelle [Galerie]::remove[Objet]() pour chacune des galeries, et on prend soin de bien faire un persist() sur ces galeries ainsi « modifiées ».

On ajoute un flush() au cas où un remove($entity) juste après annulerait le principe des persist().

Enfin, on peut supprimer l’[objet] lui-même :

    //...

        $this->getEntityManager()->remove($entity);

        if ($flush) {
                $this->getEntityManager()->flush();
        }
}

Vérifiez que cela fonctionne bien, en chargeant les fixtures, et en supprimant à nouveau tous les [inventaires] et leurs [objets] : les tables d’association des différentes ManyToMany doivent être vides. Vous pouvez aussi vérifier ce qui se passe à la suppression d’un [objet] dans un formulaire, en regardant les requêtes DELETE SQL qui sont envoyées, dans l’outil « Doctrine » de la barre d’outils Symfony.