Vous êtes sur la page 1sur 13

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

2018 – 2019

Cours 1
Module DA4.2

M. Ducongé - Barrère 1/13


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

Le framework Symfony ....................................................................................................... 3


Introduction ............................................................................................................................................. 3
Composer ................................................................................................................................................. 3
Introduction ......................................................................................................................................... 3
Installation en mode global ................................................................................................................. 3
Création d’un projet Symfony .................................................................................................................. 3
Arborescence du projet........................................................................................................................ 4
Serveur interne ........................................................................................................................................ 4
Gestion des erreurs et informations ........................................................................................................ 4
Création d’une première page ................................................................................................................. 4
Création du contrôleur ........................................................................................................................ 5
Routage .................................................................................................................................................... 5
Twig .......................................................................................................................................................... 6
Variables .............................................................................................................................................. 6
Templates et héritage ......................................................................................................................... 7
Lien dynamique dans les templates .................................................................................................... 7
Activer couleur syntaxique pour les contenus Twig dans NetBeans. .................................................. 7
Doctrine et la BDD .................................................................................................................................... 8
Paramétrage........................................................................................................................................ 8
Création d’une base ............................................................................................................................. 9
Création d’une table ............................................................................................................................ 9
Les migrations ..................................................................................................................................... 9
Reverse engineering .......................................................................................................................... 10
Fixtures ................................................................................................................................................... 11
Utilisation de Doctrine ........................................................................................................................... 11
Requêtes SQL ......................................................................................................................................... 12
Doctrine Query Language .................................................................................................................. 12
Raw SQL ............................................................................................................................................. 12

M. Ducongé - Barrère 2/13


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

Introduction

Symfony est un framework MVC libre développé en PHP par SensioLabs pour créer
rapidement des applications web. Nous utiliserons des outils comme « composer » ou
« Doctrine » pour la base de données gérée en PHP afin de faciliter et simplifier le
développement.

Ce cour est une démonstration des mécanismes de bases utilisés dans ce framework.

Composer

Introduction
« Composer » est un outils de gestion de dépendances en PHP. Il permet d’inclure, de
configurer, de mettre à jour automatiquement des librairies à votre place. C’est grâce à cet
outil que l’on va pouvoir récupérer un squelette Symfony pour créer un nouveau projet.
Installation en mode global
« Composer » est disponible à l’adresse suivante : https://getcomposer.org/download/.
Il faut suivre la procédure d’installation globale en fonction de votre système d’exploitation.
Testez que « composer » fonctionne en tapant « composer » dans la ligne de commande en
tapant : « composer -V » .

Pour plus d’informations :


https://getcomposer.org/doc/00-intro.md

Création d’un projet Symfony

Se placer dans le répertoire souhaité pour créer le projet. Ouvrir un terminal.

A l’aide de « composer », créez un projet à partir d’un squelette :


composer create-project symfony/website-skeleton nom-du-projet

Après installation, allez dans votre éditeur préféré et ouvrez son terminal interne pour faciliter
l’écriture des commandes, tout sera sur la même fenêtre. Vous pouvez donc fermer la fenêtre
du terminal où vous avez créé le projet avec « create-project ».

Si vous utilisez NetBeans, pour afficher le terminal, allez dans Tools > IDE tools > terminal et
placez-vous dans le répertoire du projet.

Vous pourrez alors interagir avec votre projet en utilisant la ligne de commande.

Pour plus d’informations :


https://symfony.com/doc/current/best_practices/creating-the-project.html

M. Ducongé - Barrère 3/13


École régionale du numérique - Développement d'une application client serveur
2018 – 2019
Arborescence du projet
Le répertoire « src » est le dossier avec lequel nous allons travailler le plus souvent. Il contient
les contrôleurs, les dossiers de gestion de la BDD.

Les fichiers de templates se trouvent dans le dossier « templates » à la racine du projet. Ces
templates sont des fichiers « twig ». Ces fichiers sont classés par dossiers, un par contrôleur.

Serveur interne

Symfony incorpore un serveur interne au projet qui servira uniquement en mode


développement et en local. Vous aurez seulement besoin de lancer WAMP ou MAMP pour la
BDD.

Le lancement du serveur build-in de Symfony se fait en ligne de commande :

php bin/console server:run

Si le web server n’existe pas, reportez-vous à la doc pour l’installer :


https://symfony.com/doc/current/setup/built_in_web_server.html

http://localhost:8000/

Si tout fonctionne correctement, une page « Welcome to Symfony » apparaît indiquant que
l’application est prête.

Les requêtes HTTP et erreurs sont affichées dans le terminal.

Gestion des erreurs et informations

Les informations de debug se trouvent dans un toolbar en bas de votre page. Lorsqu’une
erreur est captée, elle sera affichée et plus d’informations seront visibles à l’aide d’outils
natifs.

Création d’une première page

Rappel :
Une route est une URL qui pointe vers un contrôleur.
Un contrôleur est une fonction PHP que vous devez écrire pour construire la logique de votre
page.

Symfony utilise la structure MVC. Pour simplifier, les modèles pour accéder aux données sont
gérés avec « Doctrine », les vues et plus précisément la génération des templates utilisent
Twig et le contrôleur ne change pas, ce sont des classes PHP.

M. Ducongé - Barrère 4/13


École régionale du numérique - Développement d'une application client serveur
2018 – 2019
Création du contrôleur
On souhaite créer une page affichant une liste d’actualités. Pour ce faire, il faut un contrôleur
permettant de gérer la logique de la page. Allez chercher les données, définir le template à
utiliser etc.

La création d’un contrôleur ce fait grâce à une ligne de commande :


php bin/console make:controller

Lors de la création, on vous demande de renseigner le nom de votre classe correspondant au


contrôleur.
Écrivez le nom de votre contrôleur en respectant la convention de nommage de Symfony, la
première lettre en majuscule et le reste en camelCase, exemple : ActualitesController.

Cette commande a créé tout ce qui faut pour commencer à travailler, le contrôleur est dans
src/controller/ActualitesController.php et le template par défaut est dans
templates/actualites/index.html.twig.

Testez le bon fonctionnement de votre contrôleur :


http://localhost:8000/actualites

Routage

Dans la classe ActualitesController, on remarque, au-dessus de la fonction index créée par


défaut, l’annotation suivante :
/**
* @Route("/actualites", name="actualites")
*/

Cela signifie que l’on indique à Symfony que si après le nom de domaine, il y a « /actualites »,
se sera la fonction suivant l’annotation qui devra être appelée. L’attribut « name » correspond
au nom de la route. Symfony recommande cette notation.

Attention, si vous avez plusieurs routes qui sont quasiment identiques, par exemple :
/**
* @Route("/actualites/{id}", name="actualites")
*/
Et :
/**
* @Route("/actualites/semaine", name="actualites_semaine")
*/

Symfony analyse les routes dans l’ordre ou elles sont mentionnées dans la classe. Ici id peut
être un nombre ou une chaine de caractères. Par conséquent, si l’url est
www.mosite.fr/actualites/semaine la fonction liée à la route actualites/semaine ne sera jamais
appelée car elle est définie après actualites/{id} et que le paramètre {id} peut prendre pour
valeur une chaine de caractères.

Tout ce qui commence par un @ est une annotation, un raccourci.


M. Ducongé - Barrère 5/13
École régionale du numérique - Développement d'une application client serveur
2018 – 2019
Les annotations fonctionnent que si on rajoute dans la classe du contrôleur le :
use Symfony\Component\Routing\Annotation\Route;

Toutes les routes peuvent être spécifiées dans le fichier « config/routes.yaml », cela est la
même chose qu’une annotation.

actualites:
path: / actualites
controller: App\Controller\ActualitesController::index

Path correspond à l’url et « controller » au contrôleur qui sera appelé lorsque l’URL sera
identique à la valeur de « path ».

Twig

Variables
Twig est un générateur de templates, il va vous permettre d’insérer facilement des données
depuis un contrôleur et construire votre page dynamique.

Pour afficher une variable titre par exemple il suffit de faire {{ titre }}.
Pour une commande (if, for etc), il faudra utiliser {% et %} comme dans l’exemple suivant :
{% if note > 10 %}
J’ai la moyenne.
{% else %}
J’ai pas la moyenne.
{% endif %}

Twig est également fait et maintenu par SensioLabs les créateurs de Symfony. Reportez-vous
à la doc pour les autres syntaxes. On peut faire énormément de choses sur le formatage de
données, boucles, structures conditionnelles etc.

Pour faire passer des données du contrôleur au template, il faut passer un tableau en
paramètre du render comprenant le nom des variables et leurs valeurs.
Exemple :

return $this->render('blog/home.html.twig', [
'titre' => 'Bonjour'
]);
Dans le template, lorsque Twig interprètera l’instruction {{ titre }}, il remplacera cette dernière
par la valeur de la variable titre qui est Bonjour.

N’oubliez pas que chaque page doit obligatoirement avoir une réponse donc un render.

M. Ducongé - Barrère 6/13


École régionale du numérique - Développement d'une application client serveur
2018 – 2019
Templates et héritage
Afin de ne pas copier / coller du code, il est possible de faire un héritage que sein des
templates. Le cas typique est une barre de navigation qui doit être présente sur chaque page.

Le plus gros du travail est déjà fait. Il y a déjà un template de base nommé « base.html.twig »
qui contient la structure de base d’une page (balises html body etc). Ouvrez ce fichier pour
vous faire une idée.

C’est dans ce fichier que l’on va inclure la barre de navigation au-dessus du body. A titre
informatif, vous pouvez modifier entièrement la structure de la page pour qu’elle vous
convienne à 100%.

Dernière étape, la liaison avec le template de base. Pour indiquer à Twig que notre page hérite
d’un autre template, il faut rajouter l’instruction suivante dans votre template enfant :

{% extends 'base.html.twig' %}

Attention, il est obligatoire de définir dans quel endroit se placera le contenu du template
enfant dans le template parent. Pour l’inclure dans le body, il faut cibler le bloc body en Twig :

{% block body %}
// code template
{% endblock %}

Tout le contenu entre les instructions ci-dessus sera inclus entre les balises html <body> et
</body>.

L’héritage de template permet de mettre à jour rapidement tout un site en modifiant un seul
fichier.
Lien dynamique dans les templates
Il est recommandé de ne pas faire de lien href interne en statique dans les templates. Twig
permet de récupérer les routes à partir d’un nom d’une route avec la fonction « path() ».

Par exemple, en indiquant dans un lien href=’{{ path(‘’ actualites_sem’’) }}, Twig va aller
chercher une correspondance dans le name des routes et retourner la route. Le lien sera alors
href=’/actualites/semaine’.

/**
* @Route("/actualites/semaine", name="actualites_sem")
*/

Cette technique permet de changer l’adresse d’une route pour tout un site en modifiant une
seule donnée présente à un seul endroit.
Activer couleur syntaxique pour les contenus Twig dans NetBeans.
Aller dans Tools > Plugins, une fenêtre va s’ouvrir, cliquez sur Availables Plugins, tapez dans la
barre de recherche : Twig.
M. Ducongé - Barrère 7/13
École régionale du numérique - Développement d'une application client serveur
2018 – 2019

Les résultats s’affichent dans la colonne de gauche. Cochez la case sur le plugin Twig templates
puis cliquez sur install. Une fenêtre va s’ouvrir, il faut suivre les instructions à l’écran puis
redémarrer NetBeans.

Doctrine et la BDD

« Doctrine » est un outil qui va vous permettre d’interagir avec votre BDD en utilisant
uniquement du PHP. Il permet de faire du CRUD sur votre base. Les requêtes sont faites à
l’aide de « builder » en utilisant de simple objet PHP.

Pour ce faire il faut comprendre que Doctrine est divisé en 3 couches majeures :

Entity :
Une entité correspond à une table. C’est une classe PHP qui a pour propriétés tous les champs
de la table et leurs mutateurs correspondants.

Manager :
Grâce au manager, vous allez pouvoir manipuler le contenu des tables, création, mise à jour
et suppression d’enregistrement.

Repository :
Un repository permet de récupérer des données. C’est lui qui prépare les requêtes, interroge
la base et retourne le résultat.

L’idée est de rendre manipulable toute la BDD juste avec des fichiers PHP. On peut alors, grâce
à quelques lignes de commande, créer des bases, des tables etc.

Les fichiers correspondant aux entity, manager et repository ainsi que toute la configuration
se feront tout seul. Ils seront placés au bon endroit dans l’application et les fonctionnalités
seront directement utilisables.
Paramétrage
Le paramétrage de la BDD se fait dans le fichier « .env » situé à la racine du projet. Ce fichier
comporte toutes les variables d’environnements de l’application dont « DATABASE_URL ».
Cette dernière permet de définir les paramètres de connexion à votre BDD.

Il suffit de remplacer « db_user », « db_password », « db_name », l’ip du serveur et le port


pour avoir une connexion valide.

DATABASE_URL=mysql://db_user:db_password@127.0.0.1:3306/db_name

M. Ducongé - Barrère 8/13


École régionale du numérique - Développement d'une application client serveur
2018 – 2019
Création d’une base
La création d’une base de données peut se faire en ligne de commande via la console interne
de Symfony. En tapant la ligne de commande permettant la création d’une base, Symfony va
aller chercher le nom de la base, se connecter et la créer.

php bin/console doctrine:database:create

Si cette base existe déjà, un message d’erreur sera affiché dans la console.
Création d’une table
Pour la création de tables, la logique reste la même, cela se fait en ligne de commande.
N’oubliez pas de respecter la convention de nommage en camelCase.

php bin/console make:entity

Lors de la création des propriétés, l’utilisation du camelCase est également à privilégier. Lors
de la conversion du contenu de doctrine en BDD, les noms prendrons les conventions de
nommage de MySQL soit un underscore entre chaque mot et tout en minuscule.

Les types de données vous seront demandés. Ce sont les types correspondant à la propriété
de la classe. Ne mentionnez pas varchar ou autre type MySQL, ce ne sera pas un type valide.
On est dans le cadre d’une propriété d’une classe, il faudra donc pour une chaine de caractères
mentionnée un string.
Pour afficher tous les types possibles lors de la création des propriétés, tapez ? au lieu du nom
de la propriété.

Une fois que tout est paramétré, afin de transcrire les entités dans la base il faudra faire une
migration.

NB : le champs AI est créé automatiquement.

Pour plus d’informations :


https://symfony.com/doc/current/doctrine.html
Les migrations
On parle de migration quand on veut faire passer une base de données d’un état A à un état
B, par exemple dans le cas d’une création de table(s), modification(s) suppression(s) etc.

Doctrine va faire une différence entre la base et les entity créées dans l’application.

A ne pas oublier, les fichiers ont la priorité sur la base . Cela signifie que par exemple, si une
table test existe dans la base mais pas dans les entités, elle sera supprimée. La base doit
refléter exactement le contenu défini dans l’application.

Cette comparaison ce fait avec la commande suivante :


php bin/console make:migration

M. Ducongé - Barrère 9/13


École régionale du numérique - Développement d'une application client serveur
2018 – 2019
Un nouveau fichier versionné a été créé dans « src/Migrations » avec toutes les requêtes SQL
pour mettre à jour la BDD.

Il ne reste plus qu’à envoyer cette migration sur la base pour que les modifications soient
faites. Pour cela il faut utiliser la commande suivante :

php bin/console doctrine:migrations:migrate

Attention la base sera modifiée, faites un export si vous n’êtes pas sûre de vos modifications.

Si plusieurs migrations sont à faire, Doctrine les exécutera de la plus ancienne à la plus récente.
La force de ce système est que lorsqu’un autre développeur rentre dans un projet, il
récupérera tout le projet et n’aura pas à gérer la base et refaire une configuration. Avec
quelques appels à Doctrine il récupérera la dernière version de la base utilisée sur ce projet.
Reverse engineering
Partir d’une base de données existante pour faire un projet et également gérable avec
Doctrine, c’est faire du reverse engineering.

L’opération se passe en deux temps. Premièrement, il faut demander à Doctrine d’analyser la


BDD souhaitée, vérifier votre configuration de connexion avant de faire cette opération afin
d’éviter toute erreur. Doctrine va alors récupérer tous les champs et créer les classes PHP
correspondant aux tables trouvées. Tapez l’instruction suivante pour lancer cette analyse :

php bin/console doctrine:mapping:import 'App\Entity' annotation --path=src/Entity

Dans un second temps, il faudra demander à Doctrine de régénérer les getters et setters pour
pouvoir interagir normalement avec les propriétés.

php bin/console make:entity --regenerate App

Attention, si le repository n’est pas recréé c’est qu’il n’a pas été spécifié dans le fichier PHP
correspondant au contrôleur (situé dans le dossier entity). Auquel cas, il faudra rajouter la
ligne suivante dans les commentaires au-dessus de la classe voir l’exemple suivant.

* @ORM\Entity(repositoryClass="App\Repository\ArticleRepository")

Relancer la commande précédente pour régénérer correctement tous les fichiers.

Maintenant, vous pouvez utiliser Doctrine pour modifier vos données .

Voir doc :
https://symfony.com/doc/current/doctrine/reverse_engineering.html

M. Ducongé - Barrère 10/13


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

Les fixtures permettent d’insérer un jeu de données (fausses données) dans une BDD pour
pouvoir effectuer des tests lors du développement d’une application.

Nous avons besoin d’installer un nouveau bundle dans notre application gérant ces fixtures.
Pour ce faire, nous allons utiliser composer :
composer require orm-fixtures –dev

NB : Mettre –dev signifie que seul l’environnement de développement aura accès aux fixtures.

Pour créer une nouvelle fixture, il faut réutiliser la console de Symfony :


php bin/console make:fixtures

Symfony nous demande de donner un nom à cette nouvelle fixture. Par convention, si c’est
pour la table Article, le nom sera ArticlesFixtures. Une nouvelle classe ArticlesFixtures a été
créée dans « src/DataFixtures ».

C’est dans la fonction load que nous allons définir notre jeu de données. Cette fonction prend
en paramètre le manager de Doctrine expliqué un peu plus tôt. Au travers de ce dernier, nous
pouvons agir sur la BDD. Il suffit alors de cibler la table et de lui passer des données à insérer.

L’exécution du jeu de données se fait via la ligne suivante :


php bin/console doctrine:fixtures:load

Utilisation de Doctrine

Dans la classe contrôleur, il faut spécifier quel entity et repository devra être inclus afin de
pouvoir faire des requêtes sur la base de données.

use App\Entity\Article;
use App\Repository\ArticleRepository;

Symfony intègre automatiquement un système d’injection de dépendances afin de faciliter


l’utilisation de Doctrine dans vos méthodes comme ci-dessous. En mettant en paramètre le
repository devant une variable comme ci-dessous, la variable $repo sera assignée et rendu
directement utilisable dans la méthode.

public function index(ArticleRepository $repo)


{
$articles = $repo->findAll() ;
return $this->render('blog/index.html.twig', [
'articles' => $articles,
]);
}
La méthode « findAll() » récupère tout le contenu de la table article sans écrire une seule ligne
de SQL. Pour passer ces données à la vue donc à Twig, il faut rajouter un paramètre, un tableau
au render.

M. Ducongé - Barrère 11/13


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

Il est bien sur possible de faire des requêtes SQL brutes au travers de Symfony et Doctrine. Il
y a même deux moyens de le faire. Doctrine intègre un langage propre permettant de
récupérer des résultats au travers d’une requête texte dérivé du SQL, le Doctrine Query
Language (DQL). L’autre moyen est la requête brute 100% SQL.

Les requêtes sans l’ORM sont placées dans le repository correspondant à votre table. Elles
sont appelées via l’injection de dépendance.
Doctrine Query Language
Le DQL est un mélange de SQL et de fonctionnalités de Doctrine. Il retournera un tableau
d’objets en relation avec les propriétés de la classe PHP Entity permettant d’accéder à votre
table au travers d’ojets. Par exemple, si vous avez dans votre Entity la propriété createdAt,
vous devrez utiliser createdAt dans votre template et non le nom du champs dans votre BDD.

Utilisation :

public function getAllArticlesDQL() {

$entityManager = $this->getEntityManager();

$query = $entityManager->createQuery(
'SELECT a
FROM App\Entity\Article a
ORDER BY a.id DESC'
);

// returns an array of Product objects


return $query->execute();
}

On remarque que Doctrine intervient au niveau du FROM pour aller récupérer les propriétés
dans l’ORM. Ces données se trouvent dans « a » et seront utilisées pour faire des sélections
et conditions.

Raw SQL
L’autre méthode est la rédaction d’une requête « plain text » en SQL uniquement et de
retourner un simple tableau de données. La différence avec le DQL c’est qu’ici, les noms des
champs seront basés sur votre BDD et non sur les propriétés définies dans l’ORM. Par
exemple, dans la base de données le champs s’appelle « created_at », vous devrez donc
utiliser ce nom pour afficher cette donnée.

M. Ducongé - Barrère 12/13


École régionale du numérique - Développement d'une application client serveur
2018 – 2019
Utilisation :
public function getAllArticlesSQL() {

$sql = 'SELECT * FROM article';


$conn = $this->getEntityManager()->getConnection();

$stmt = $conn->prepare($sql);

$stmt->execute();

// returns an array of arrays (i.e. a raw data set)


return $stmt->fetchAll();
}

M. Ducongé - Barrère 13/13

Vous aimerez peut-être aussi