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 (README.md) ou org-mode (README.org), 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/
   

Vous allez utiliser Git pour gérer les fichiers source du projet au fur et à mesure de votre avancement. Pour cela, Git doit être configuré de façon à ce que votre identité soit visible dans l’historique des instantannés (commits).

1. Vérifiez si vous avez une configuration des variables de configuration de Git adaptée :

   git config user.email
   

2. Si la commande précédente n’affiche rien, procédez à la définition de cette variable en remplaçant [votre email] par votre email école (...@telecom-sudparis.eu).

   git config --global user.email "[votre email]"
   

3. Procédez de même pour votre nom :

   git config --global user.name "[votre Prénom Nom]"
   

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 --debug new [nom-code] --version=lts --webapp

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

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

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

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 d’un certain nombre d’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 (sauf pour « Membre », voir ci-dessous)
   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;

   On va lui ajouter une propriété multi-valuée, de type relation (OneToMany), qu’on pourra nommer « [objets] » (au pluriel);

   On codera les Fixtures chargeant ces associations avec des références (comme expliqué ci-dessus).

   Exemple d’exécution du générateur de code :

   $ symfony console make:entity
   
    Class name of the entity to create or update (e.g. GrumpyGnome):
    > Rack
   
    Your entity already exists! So let's add some new fields!
   
    New property name (press <return> to stop adding fields):
    > guitars
   
    Field type (enter ? to see all types) [string]:
    > relation
   
    What class should this entity be related to?:
    > Guitar
   
   What type of relationship is this?
    ------------ ------------------------------------------------------------------- 
     Type         Description                                                        
    ------------ ------------------------------------------------------------------- 
     ManyToOne    Each Rack relates to (has) one Guitar.                             
                  Each Guitar can relate to (can have) many Rack objects.            
   
     OneToMany    Each Rack can relate to (can have) many Guitar objects.            
                  Each Guitar relates to (has) one Rack.                             
   
     ManyToMany   Each Rack can relate to (can have) many Guitar objects.            
                  Each Guitar can also relate to (can also have) many Rack objects.  
   
     OneToOne     Each Rack relates to (has) exactly one Guitar.                     
                  Each Guitar also relates to (has) exactly one Rack.                
    ------------ ------------------------------------------------------------------- 
   
    Relation type? [ManyToOne, OneToMany, ManyToMany, OneToOne]:
    > OneToMany
   
    A new property will also be added to the Guitar class so that you can access and set the related Rack object from it.
   
    New field name inside Guitar [rack]:
    > 
   
    Is the Guitar.rack property allowed to be null (nullable)? (yes/no) [yes]:
    > no
   
    Do you want to activate orphanRemoval on your relationship?
    A Guitar is "orphaned" when it is removed from its related Rack.
    e.g. $rack->removeGuitar($guitar)
   
    NOTE: If a Guitar may *change* from one Rack to another, answer "no".
   
    Do you want to automatically delete orphaned App\Entity\Guitar objects (orphanRemoval)? (yes/no) [no]:
    > yes
   
    updated: src/Entity/Rack.php
    updated: src/Entity/Guitar.php
   
    Add another property? Enter the property name (or press <return> to stop adding fields):
    > 
   
   
   
     Success! 
   
   
    Next: When you're ready, create a migration with symfony console make:migration
   
   

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

Note : on détaille plus loin la création de l’entité [galerie], qui peut n’intervenir que dans un temps ultérieur (cf. Ajout de l’entité [galerie] au modèle des données).

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.

Lisez cette introduction avant de passer à la mise en oeuvre dans la section suivante.

Vous allez générer ci-après 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. C’est à dire celle utilisée par les membres de la communauté hébergée sur le site.

On va commencer avec des étapes détaillées pour la première entité, [inventaire], puis vous deviendrez plus autonomes.

Pour chaque entité, le même processus se répétera : 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 de consultation.

Ces avertissements étant faits, passons au concret sur les premières pages de consultation.

Pour l’instant, on va afficher deux pages permettant de consulter :

• la liste des [inventaires], qui sera destinée aux administrateurs ;
• la consultation d’un [inventaire] particulier, destinée elle au membre propriétaire de cet inventaire.

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.

Procédez aux opérations suivantes :

1. 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
   

2. Modifiez la méthode correspondante de la classe controleur, pour réaliser l’affichage des [inventaires]

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] de tous les membres :
    <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.

Une fois que vous avez ajouté l’affichage de la liste des [inventaires], vous pourrez continuer avec d’autres pages gérées par le même controleur.

Ajoutez 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) : Response
{
        $[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 ToDoController vu en TP). 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.

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 title %}[Inventaire] n°{{ [inventaire].id }}{% endblock %}

{% 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].

Ajoutez l’appel à render() de Twig correspondant, dans la méthode du Controleur des [inventaires].

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.

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" />
        <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no" />
        <meta name="description" content="" />
        <meta name="author" content="" />
        <title>{% block title %}Welcome!{% endblock %}</title>
        <!-- Favicon-->
        <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.

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') }}">[nom-code]</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]/

Modifiez le gabarit de la page de consultation d’une [galerie], pour y afficher la liste des [objets] présents dans cette [galerie].

Vous pouvez vous inspirer de l’affichage d’une liste similaire que vous avez déjà faite dans templates/[inventaire]/show.html.twig :

<tr>
    <th>[Objets]</th>
    <td>
        <ul>
          {% for [objet] in [galerie].[objets] %}
          <li>
            {{ [objet] }}
          </li>
          {% endfor %}
        </ul>
    </td>
</tr>

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 des [galeries] avec Bootstrap.

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

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 [inventaire], et de là aux [objets], etc.

1. Ajoutez une classe Contrôleur pour l’entité Membre, avec make:controller (cette fois, il s’agit de consulter les membres, dans le front-office : pas besoin d’un CRUD. S’il y a un CRUD des membres, ce sera pour le back-office).
2. Ajoutez deux méthodes index() et show(), et le contenu des gabarits correspondants, comme on l’a fait auparavant pour d’autres entités, pour afficher :
   • la liste des membres (celle-ci aura vocation à disparaître ultérieurement). Inspirez-vous du code de [Galerie]Repository::index(), par exemple;
   • et la fiche de chaque membre. Inspirez-vous de [Galerie]Repository::show(), par exemple.

3. Dans la fiche d’un membre, affichez un lien vers la consultation de son inventaire :

   Par exemple, on obtiendrait ceci dans le gabarit templates/member/show.html.twig :

   <a href="{{ path('app_[inventaire]_show', {'id' : member.[inventaire].id}) }}"> mon [inventaire] </a>
   

4. Dans la consultation d’un inventaire, le lien de retour doit revenir vers le membre et non-plus vers la liste des inventaires

   <a href="{{ path('app_member_show', {'id': [inventaire].member.id}) }}">back to member</a>
   

On doit maintenant ajuster la création d’un nouvel [objet], qui dépendra alors du membre courant, pour l’ajouter dans le bon inventaire.

La route app_[objet]_new changera donc pour prendre en compte ce nouveau contexte où on passe l’identifiant de l’[inventaire] en argument.

1. Modifiez la route CRUD de création d’un nouvel [objet] :

   Extrait de src/Controller/[Objet]Controller.php :

   #[Route('/[objet]/new/{id}', name: 'app_[objet]_new', methods: ['GET', 'POST'])]
   public function new(Request $request, EntityManagerInterface $entityManager, [Inventory] $inventory): Response
   {
       $objet = new [Objet]();
       $objet->setInventory($inventory);
   
       //...
   
       if ($form->isSubmitted() && $form->isValid()) {
           //...
   
           return $this->redirectToRoute('app_[inventaire]_show',
                                         ['id' => $inventory->getId()],
                                         Response::HTTP_SEE_OTHER);
       }
   

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

2. Déplacez le lien de création d’[objet] : supprimez-le de la page de liste des [objets] (templates/[objet]/index.html.twig) pour le placer dans l’affichage de l’[inventaire] (templates/[inventaire]/show.html.twig), et modifiez l’appel de la route :

   <a href="{{ path('app_[objet]_new', {'id': [inventaire].id}) }}">Add new</a>
   

3. On peut alors ajouter une customisation du formulaire de création pour ne pas autoriser la modification de l’attribut [inventaire] d’un [objet], puisqu’il est fixé par le contexte d’invocation.

   Ainsi dans la classe gérant le formulaire src/Form/[Objet]Type.php :

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

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

4. Modifiez la redirection en fin de modification d’un [objet] pour rediriger de la même façon vers la page de son [inventaire], plutôt que vers la liste des [objets] :

   ...redirectToRoute('app_[inventaire]_show', ['id' => $[objet]->get[Inventaire]()->getId()], Response::HTTP_SEE_OTHER);

5. Modifiez la redirection en fin de suppression d’un objet pour revenir à la page de son [inventaire]

Ajoutez la consultation de la liste des [galeries] d’un membre, dans la page de consultation du Membre.

Copiez le code du gabarit gabarit utilisé par index() dans le contrôleur [Galerie]Controller, pour l’ajouter dans celui utilisé par MemberController::show().

Adaptez, pour afficher la liste des galeries du membre.

On doit ensuite modifier la création d’une nouvelle [galerie] pour qu’elle soit contextualisée à partir du membre (cf. étape ci-dessus pour la contextualisation de la création des [objets] dans un [inventaire]).

On ajoute enfin le lien de création dans la page de consultation du Membre, et on le supprime de la page de consultation de la liste des galeries.

De façon similaire, on doit répercuter le même genre de changements sur les redirections en fin de modification ou suppression d’une [galerie].

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]).

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

Au lieu de tout rassembler dans le code d’une seule classe AppFixtures, on peut séparer le code dans différents fichiers source. Il suffit alors d’ajouter, à côté du fichier src/DataFixtures/AppFixtures.php existant, un nouveau fichier source UserFixtures.php récupéré du code de Todo, en y adaptant le nom de la classe (en remplaçant User par Member).

Si on utilise ainsi deux fichiers source, on est alors potentiellement confronté à l’ordre de chargement des données des fixtures des Membres par rapport à celles des [Inventaires]. 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, dans AppFixtures charger d’abord les instances de Member, puis s’y relier à la création des [Inventaires] associés, en chargeant les Membres par leur email, avec findOneByEmail() :

foreach (self::[Inventaire]DataGenerator() as [$name, $memberemail] ) {
        $[inventaire] = new [Inventaire]();
        if ($memberemail) {
                $member = $manager->getRepository([Inventaire]::class)->findOneByEmail($memberemail);
                $[inventaire]->setUser($member);
        }
        $[inventaire]->setName($name);
        $manager->persist($[inventaire]);
}
$manager->flush();

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() == $[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), 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 {
                $member = $this->getUser();
                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 verbeux, mais compliqué à écrire car on n’est pas sûr qu’un utilisateur soit connecté, et on doit donc progresser en testant l’existance des instances avant d’appeler leur méthodes.

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 {
                $member = $this->getUser();
          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 devient complexe, et pourrait probablement receler beaucoup des 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é :

$private[Galeries] = array();
$member = $this->getUser();
if($user) {
        $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();
                $[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.

On va devoir coder le chargement de données liées entre-elles. Pour cela, yield va nous permettre d’itérer dans des tableaux définis dans le code.

Pour la gestion des entités liées entre-elles, on devra identifier des entitées dans ces tableaux. Pour simplifier celà, on pourra utiliser des références à des objets, une des fonctionnalités du module de Fixtures. C’est documenté dans la documentation du module DoctrineFixturesBundle.

Par exemple, pour l’ajout de guitares dans des racks, supposons qu’on a deux entités, resp. Guitar et Rack.

Mettons qu’on ait 2 racks :

• « Matos guitare d’Olivier »
• « 400 guitars collection »

On peut avoir 3 guitares, qu’on souhaite répartir ainsi :

• « Epiphone SG Special P-90 » et « Ibanez SA360NQM » dans le rack « Matos guitare d’Olivier »
• « Gibson Les Paul 1960 », dans le rack « 400 guitars collection »

Le code des fixtures va commencer par charger l’entité Rack dans la base, puis faire le chargement de l’autre entité Guitare.

Au moment de créer les guitares, les racks existent déjà, et pour ranger les guitares dans leurs racks on souhaterait identifier les racks de façon simple dans notre code. Plutôt que de devoir gérer le nom littéral de chaque rack, on va leur associer des identifiants, qui seront des constantes de la classe. Cela aura l’avantage de permettre à l’IDE de faire de la complétion, sur le nom de ces constantes, plutôt que sur des chaînes où on peut faire des erreurs de typo.

On utilisera addReference() et getReference() pour donner un tel identifiant à chaque rack.

On peut donc utiliser un code du genre :

<?php

namespace App\DataFixtures;

class AppFixtures extends Fixture
{
    // defines reference names for instances of Rack
    private const SLASH_RACK = 'slash-inventory';
    private const OLIVIER_RACK = 'olivier-inventory';

    /**
     * Generates initialization data for racks : [title, rack reference]
     * @return \\Generator
     */
    private static function rackDataGenerator()
    {
        yield ["Matos guitare d'Olivier", self::OLIVIER_RACK];
        yield ["400 guitars collection", self::SLASH_RACK];
    }

    /**
     * Generates initialization data for guitars :
     *  [rack reference, guitar description]
     * @return \\Generator
     */
    private static function guitarsGenerator()
    {
        yield [self::OLIVIER_RACK, "Epiphone SG Special P-90"];
        yield [self::OLIVIER_RACK, "Ibanez SA360NQM"];
        yield [self::SLASH_RACK, "Gibson Les Paul 1960"];
    }

    public function load(ObjectManager $manager)
    {
        // $inventoryRepo = $manager->getRepository(Rack::class);

        foreach (self::rackDataGenerator() as [$title, $rackReference] ) {
            $rack = new Rack();
            $rack->setTitle($title);
            $manager->persist($rack);
            $manager->flush();

            // Once the Rack instance has been saved to DB
            // it has a valid Id generated by Doctrine, and can thus
            // be saved as a future reference
            $this->addReference($rackReference, $rack);
        }

        foreach (self::guitarsGenerator() as [$rackReference, $model])
        {
            // Retrieve the One-side instance of Rack from its reference name
            $rack = $this->getReference($rackReference);
            $guitar = new Guitar();
            $guitar->setDescription($model);
            // Add the Many-side Guitar to its containing rack
            $rack->addGuitar($guitar);

            // Require that the ORM\OneToMany attribute on Rack::guitars has "cascade: ['persist']"
            $manager->persist($rack);
        }
        $manager->flush();
    }
}

Quelques explications :

• OLIVIER_RACK et SLASH_RACK sont nos constantes qui jouent le rôle d’identifiant, dans cette classe seulement. Ici, ce qui importe c’est qu’elles aient des valeurs (chaînes de caractères) uniques, quelconques. On va les manipuler dans le code qu’on écrit, par leur nom de constante, connu de l’IDE car déclaré (private const ...) : cela évite des typos.
• le yield dans le rackDataGenerator() renvoie l’identifiant OLIVIER_RACK ou SLASH_RACK qui est attribué via addReference() suite au new Rack()
• le yield dans le guitarsGenerator() réutilise ces même identifiant, qui serviront à faire des getReference() pour rechercher le rack ($rack) sur lequel faire le $rack->addGuitar($guitar) qui associe la guitare au bon rack. Cela évite un code plus lourd à écrire, qui utiliserait find().

Normalement, ça se lit comme de l’objet, et ça évite de devoir gérer des identifiants interne en base de données où à faire des requêtes de recherche des racks dans la base.