TP Symfony - Gestion des modèles de données

Ce TP est une mise en application du cours présenté en classe. Le but principal est la création de modèles de données persistants à l’aide de Doctrine.

Groupes et GIT

Ce projet est un TP de groupe. Les groupes peuvent êtres constitués de 2 ou 3 personnes. Pas plus, pas moins.

L’organisation du travail de groupe, la répartition de tâches et l’équilibre des contributions de chacun, font partit du travail demandé et seront pris en compte dans l’évaluation.

Les projets GIT sont à créer sur la forge de l’université. Le contenu et la régularité de validations (commits) attestera des contributions de chacun.

Ne pas oublier de donner les droits developer aux enseignants (messieurs Fournier et Pigné).

Ce projet débute le TP final du cours d’InfoWeb. Ce dépot GIT va être utilisé/amélioré jusqu’au dernier TP.

Chaque groupe constitué doit désigner un référent qui se charge de créer le projet GIT et le projet Symfony, puis d’envoyer un courriel aux enseignants avec les noms des membres, le numéro de sujet choisi et l’URL du projet.

Échéances

Deux sujets au choix

Vous avez le choix entre deux sujets de TP. N’en choisissez qu’un seul !

Le sujet n°1 consiste à utiliser à nouveau votre base du Projet BD du premier semestre et de refaire un site CRUD entièrement avec Symfony. L’avantage de ce sujet est que vous maîtrisez la structure de la base. L’inconvénient est que c’est une structure parfois complexe avec de nombreuses associations.

Le sujet n°2 consiste à utiliser une nouvelle source de données, plus simple, qui ne contient qu’une seule entités principale et une seule association 1-n. L’avantage de ce sujet est la simplicité du modèle de données. L’inconvénient est qu’il y a un travail d’importation et d’adaptation des données à partir d’une source au format texte (CSV, ou JSON).

Indications valable pour les deux sujets :

Sujet n°1

En reprenant les bases de données réalisée en Projet BD, réaliser les entités Symfony et les contrôleurs associées à ces données permettant de lister toutes les données des tables, de visualiser une donnée en fonction de son id et d’éditer les données. Par exemple, pour une table nomRelation, les routes suivantes sont attendues :

Les pages générées doivent répondre à un design responsive homogène.

Dans cette étape aucun formulaire n’est demandé, les méthodes d’éditions devront simplement insérer des données aléatoires ou modifier de façon arbitraire les enregistrements ciblés.

Les tables associatives many-to-many ne seront pas considérées.

Chaque entité sera associé à un contrôleur spécifique afin de favoriser le travail de chacun des membres de l’équipe.

Sujet n°2

On propose de traiter la liste des établissements d’enseignement de premier et second degré. On souhaite pouvoir lister les établissements en fonction de leur localisation (commune, département, académie, région). Outre la visualisation, on souhaitera plus tard pouvoir créer, modifier et supprimer un établissement. Enfin on veut mettre en place un mécanisme de commentaires sur ces établissements.

une entité

Une entité principale Établissement doit être conçue. Le schéma exacte est a déterminer en fonction des informations à votre disposition.

A minima, un établissement aura les champs suivants :

Le champ “secteur” sera traité comme une énumération.

un contrôleur

Un contrôleur principal permettra les actions CRUD sur ce model. Pour l’instant il n’est pas demandé de faire des formulaires de création, de modification ou de suppression. On se concentre sur les routes de visualisation.

La visualisation par liste doit se faire par catégorie (département, région, commune, académie). On doit donc prévoir les routes adéquates par exemple :

Import des données

Des données sources sont disponibles sous Licence Ouverte pour alimenter ce model. Les noms des champs du model ne doivent pas forcément correspondre à ceux du fichier.

On peut bien sur ouvrir ce fichier CSV avec Excel, récupérer les colonnes intéressantes et se débattre un peu avec DataGrip ou PhpMyAdmin pour importer les données directement dans la base… Mais ce n’est pas la bonne méthode.

La bonne méthode c’est d’écrire un script d’import en PHP qui va télécharger les données et créer des instance de l’entité Établissement et les faire persister en base. Pour ça on utilise DoctrineFixturesBundle: https://symfony.com/doc/current/bundles/DoctrineFixturesBundle/index.html

On aura besoin d’interpréter les données en fonction du format utilisé :

Des commentaires

On souhaite que le site affiche une liste de commentaires associés à chaque établissement.

Un commentaire peut être constitué de :

Prévoir cette nouvelle entité en relation 1-n avec l’entité établissement. Attention au sens de la relation. Un établissement peut avoir plusieurs commentaires et un commentaire ne concerne qu’un seul établissement.

Se concentrer sur l’affichage plutôt que sur la création des commentaire. Les formulaires seront abordés plus tard.