Vous êtes sur la page 1sur 8

École régionale du numérique - Développement d'une application client serveur

2018 – 2019

Cours 2
Module DA4.2

M. Ducongé - Barrère 1/8


École régionale du numérique - Développement d'une application client serveur
2018 – 2019

Symfony ................................................................................................................................. 3
Introduction ........................................................................................................................................ 3
Gestion des données HTTP ................................................................................................................. 3
Formulaires ........................................................................................................................................ 3
Le « builder » de formulaires ......................................................................................................... 3
Validation du formulaire ................................................................................................................ 4
Liaison avec une entité ................................................................................................................... 4
Ligne de commande ....................................................................................................................... 5
Restriction des données et messages d’erreurs ............................................................................... 5
Upload de fichier ........................................................................................................................... 6
Relations entre entités ......................................................................................................................... 6
Création de la relation ................................................................................................................... 6
Enregistrement avec une entité liée ................................................................................................ 8

M. Ducongé - Barrère 2/8


École régionale du numérique - Développement d'une application client serveur
2018 – 2019

SYMFONY

Introduction

Le cours suivant est un support pour vous aider à développer votre application en expliquant
globalement la démarche à appliquer pour répondre à une problématique. L’idée est de ne pas
refaire une documentation de Symfony mais d’avoir en quelques lignes un aperçu de ce qui
existe déjà et de savoir l’utiliser. Enjoy !!

Gestion des données HTTP

Symfony intègre sous un seul objet la gestion des données POST, GET, SESSIONS etc. Ces
variables sont stockées sous forme de listes d’objets nommées « parameter bags ».

Pour accéder aux données, il faut utiliser la classe « Request » présente dans
« HttpFoundation », n’oubliez pas d’inclure le namespace suivant :

use Symfony\Component\HttpFoundation\Request;

Vous pouvez utiliser l’injection de dépendance ( chargement de la classe à partir d’un paramètre
formel, voir image ci-dessous) pour utiliser rapidement cette fonctionnalité. Afin de
comprendre toute l’étendue des données présentent dans Request, je vous invite à faire un
dump() de cette dernière et d’examiner sa structure.

public function edit(Request $request, ObjectManager $manager)


{
}

Exemple de cas d’utilisation : c’est au travers de cette classe que l’on peut savoir si un
formulaire a été validé, que les informations sont correctes et de récupérer son contenu.

Pour plus d’informations :


https://symfony.com/doc/current/components/http_foundation.html
https://symfony.com/doc/current/introduction/http_fundamentals.html

Formulaires

Il existe plusieurs manières de créer un formulaire. La plus classique est de créer une structure
html avec les champs voulus, vérifier si l’on a des résultats et traiter les données en PHP. Les
développeurs de Symfony ont pensé à intégrer un outil très pratique permettant de faciliter cette
tâche, le « builder ».
Le « builder » de formulaires
La construction des formulaires est largement simplifiée grâce au « builder » interne au
framework, « createFormBuilder ». C’est une classe accessible directement depuis « $this »
utilisant la fonction « add() » pour ajouter des champs dans un formulaire comme sur l’exemple
dans la page suivante.

M. Ducongé - Barrère 3/8


École régionale du numérique - Développement d'une application client serveur
2018 – 2019

$form = $this->createFormBuilder($article)
->add('title')
->add('description')
->getForm();

Pour passer le formulaire HTML à la vue, il ne faut pas oublier d’utiliser la fonction
« createView() » dans le render de votre méthode.

L’idée est de définir la structure du formulaire et de le mettre en forme avec Twig dans le
template. Twig permet de modifier facilement les labels et attributs html directement dans le
template (voir doc).
Validation du formulaire
Pour savoir si un formulaire a été validé, c’est à dire que l’utilisateur a déclenché un « submit »,
il faut récupérer la requête à l’aide de la classe « Request » situé dans l’espace de nom
« HttpFoundation ». La liaison entre le formulaire et la requête se fait en passant en paramètre
de « handleRequest() » la variable correspondant à la classe « Request ».

$form->handleRequest($request);

De cette manière, la validation se fait à l’aide de deux fonctions, « isSubmitted() » et


« isValid() ». Elles permettent de savoir si un utilisateur a validé un form et si les données sont
valides.

if($form->isSubmitted() && $form->isValid()){ }

Liaison avec une entité


La création d’un formulaire peut être lié à une entité ce n’est pas obligatoire mais c’est là que
se situe toute la force du système. Grâce à cette liaison, lorsque vous allez passer à votre vue
les propriétés à afficher, les types de champs définis dans entity vont être récupérés et serviront
à choisir quel est l’input le plus adéquat.

Par exemple, pour une propriété de type text désignant une description, le système comprendra
de lui-même qu’il faudra un champ textarea dans le form.
Ces champs sont évidemment modifiables pour plus de souplesse en utilisant « TextType »,
« DateType » etc (voir docs).

L’autre avantage est lorsque vous passez à votre « form » un enregistrement, le formulaire sera
directement rempli avec les données contenues dans votre BDD. De plus, lors de
l’enregistrement ou de la modification, à l’aide de « Request », les données seront placées dans
votre objet entité. Un « persist() » et un « flush() » et vos données seront dans votre BDD.

M. Ducongé - Barrère 4/8


École régionale du numérique - Développement d'une application client serveur
2018 – 2019

Ligne de commande
Les formulaires peuvent également être générés en tapant la ligne de commande suivante :
php bin/console make:form

Cette dernière va vous demander quel est le nom de la classe pour votre futur formulaire.
Attention, la convention de nommage à respecter est de suffixer le nom de votre formulaire
avec « Type » comme dans l’exemple dans la CLI. Renseignez ensuite le nom de l’entité qui
devra être liée à ce formulaire.

Un nouveau dossier « Form » sera créé dans le répertoire « src » s’il n’existe pas. Il contiendra
toutes les logiques des formulaires sous forme de classe PHP. Si vous ouvrez ce fichier, vous
pouvez constater que tous les champs liés à votre entité sont renseignés dans le « builder », vous
pouvez bien évidement ajouter/supprimer des champs.

Pour appeler ce formulaire, utiliser tout simplement « $this » et n’oubliez pas de spécifier le
formulaire et l’entité dans les paramètres formel.

$form = $this->createForm(ArticleType::class, $article);

Le gros avantage est la réutilisation de ce formulaire dans plusieurs pages de votre site. En
centralisant de la sorte, vous n’aurez plus qu’un seul endroit à modifier.
Restriction des données et messages d’erreurs
Les formulaires sont un point sensible dans un site internet. Par conséquent, il faut contraindre
l'utilisateur à renseigner les données attendues mais également lui indiquer ce qu’il ne va pas
dans sa saisie.

Les contraintes se définissent au sein de l’entité au-dessus des propriétés, dans les
commentaires. Elle seront directement intégrées dans l’HTML de votre formulaire.

Avant de définir quel sera les restrictions, il faut indiquer à Symfony où se trouve ces
contraintes. N’oubliez pas d’inclure le namespace suivant dans votre fichier entité :

use Symfony\Component\Validator\Constraints as Assert;

NB : « Assert » est juste un alias pour la classe « Constraints ».

La gestion de l’affichage des erreurs se fait dans la vue. Utilisez des thèmes « Bootstrap » pour
vous faciliter la mise en forme.

Pour plus d’informations :


https://symfony.com/doc/current/forms.html
https://symfony.com/doc/current/reference/forms/twig_reference.html
https://symfony.com/doc/current/validation.html
https://symfony.com/doc/current/form/form_customization.html#twig

M. Ducongé - Barrère 5/8


École régionale du numérique - Développement d'une application client serveur
2018 – 2019

Upload de fichier
L’upload d’un fichier au travers d’un formulaire ce fait à l’aide des contraintes « Assert » dans
une entité et d’un « FileType ». Ce typage se fait lors de la construction de la logique du
formulaire dans le « builder ».

->add('brochure', FileType::class, array('label' => 'Brochure (PDF file)'))

Dans l’entité concernée par l’upload, au-dessus de la propriété qui servira pour le nom du
fichier, il est recommandé de faire une liste des fichiers autorisés à partir du type mime comme
ci-dessous.

* @Assert\File(mimeTypes={ "application/pdf" })

La logique de l’upload se passe évidemment dans le contrôleur correspondant à votre page. La


mécanique consiste à définir un nom unique, le déplacer dans un répertoire donné et
d’enregistrer les données dans la base (voir doc).

Le paramétrage du répertoire ou seront envoyé vos fichiers est à définir dans


« config/service.yaml » sous la propriété « parameters ».

parameters:
brochures_directory: '%kernel.project_dir%/public/uploads/brochures'

Si les dossiers « uploads » et « brochures » n’existent pas, il seront créés lors du premier
« uploads ».

Pour plus d’informations :


https://symfony.com/doc/current/controller/upload_file.html

Relations entre entités

La relation entre entités permet de faire des liaisons entre tables, 1 à n, n à n, n à 1, au sein de
votre application. Elle se fait à l’aide de Doctrine.
Création de la relation
La création d’une relation se fait à l’aide de la ligne de commande, de la même manière que
pour l’ajout d’une nouvelle entité. La CLI vous demandera tous les champs que vous souhaitez
ajouter et c’est à ce moment que vous pourrez déclarer une relation en choisissant un type de
relation (OneToMany, ManyToMany, ManyToOne) ou « relation ».

Ce dernier est une aide, elle affiche une petite description de l’effet de chaque relation entre les
entités concernées.

M. Ducongé - Barrère 6/8


École régionale du numérique - Développement d'une application client serveur
2018 – 2019

L’étape suivante est la configuration des champs relatifs à la relation. C’est à dire quel champ
dans la table A et la table B permettra d’identifier cette association. La CLI vous demandera de
choisir un nom et indiquer si ce dernier peut être null ou non.
Attention, si vous avez des données en BDD et que vous renseignez que le champ ne peut pas
être null, votre migration ne se fera pas correctement. Des données étant déjà renseignées dans
la table n’auront pas de valeur donc null, or le champ ne peut pas être null. Par conséquent la
mise à jour ne sera pas correctement effectuée.

Deux solutions sont possibles, définir que le champs créé peut être null ou supprimer les
anciennes données. La première est à privilégier.

Lors de la configuration, une fonctionnalité de suppression automatique vous est proposée. Cela
signifie que par exemple lorsqu’un article sera déplacé d’une catégorie A vers B, cet article sera
supprimé automatiquement. Si ce n’est pas le comportement recherché, répondez no dans la
CLI. Attention, cette suppression automatique peut causer des pertes de données si elle est mal
configurée.

Pour plus d’informations :


https://symfony.com/doc/current/doctrine/associations.html
https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/reference/working-with-
associations.html#orphan-removal
https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/reference/unitofwork-
associations.html

M. Ducongé - Barrère 7/8


École régionale du numérique - Développement d'une application client serveur
2018 – 2019

Enregistrement avec une entité liée


Lorsqu’une relation est faite entre deux entités, un article et une catégorie par exemple, et que
les propriétés représentant cette relation sont non null, vous devez obligatoirement définir la
liaison avec la catégorie. Une erreur sera affichée le cas échéant.

Dans le cas d’ajout d’un enregistrement en BDD (formulaire), pour respecter cette relation, il
faut définir dans la création du formulaire qu’un champ ne sera pas une entité mais une relation.
Dans « choice_label » il faudra spécifier le nom du champ de la BDD à afficher dans le
template. Voir code ci-après.

->add('category', EntityType::class, [
'class' => Category::class,
'choice_label' => 'title']
)
Lorsque vous afficherez dans la vue la variable Twig « category », celle-ci sera remplacée par
une liste déroulante contenant toutes les catégories. N’oubliez pas d’ajouter les namespace pour
les entités.

Pour plus d’informations :


https://symfony.com/doc/current/doctrine/associations.html
https://symfony.com/doc/4.1/reference/forms/types/entity.html

M. Ducongé - Barrère 8/8