Alphorm.com Support de la Formation Symfony 3 , les fondamentaux-ss

18/03/2016
1
Formation Symfony3, les fondamentaux alphorm.com™©
Michel CADENNES
Formateur et Consultant indépendant
Web, Gestion des connaissances
Site : http://www.alphorm.com
Blog : http://blog.alphorm.com
Symfony 3,
les fondamentaux

18/03/2016
2
Plan
Présentation du formateur
Pourquoi Symfony ?
Symfony 2 ou 3 ?
Les objectifs du cours
Le plan du cours
Une application pour jouer avec l’environnement Symfony
A qui s’adresse la formation ?
Les pré-requis

18/03/2016
4
Pourquoi Symfony ?
PHP est la « lingua franca » du web
Symfony 2 est le premier framework « moderne » pour PHP
L’environnement offre une vision architecturale claire
C’est une boîte à outils et non un CMS (voire un CMF)
Les composants sont de plus en plus utilisés dans nombre d’outils PHP :
Drupal, Laravel, Goutte, PHPBB, Piwik,…
Symfony encourage les bonnes pratiques d’équipe de développement

18/03/2016
5
Symfony 2 ou 3 ?
Les versions supportées actuellement sont la 2.7 et la 2.8
La philosophie de SensioLabs a été depuis la version 2.3 de ne pas
retirer les fonctions déclarées obsolètes
La version 3.0 procède principalement à un nettoyage du code source
La très grande majorité du code compatible avec les versions 2.x
récentes le sera encore avec la version 3
La version 3.0 n’est pas LTS : des changements peuvent encore
intervenir dans les mois qui viennent.

18/03/2016
6
Objectifs
Le but de ce cours est d’expliquer les fondements de l’architecture
d’une application dans l’environnement Symfony :
Découvrir les composants principaux proposés par Symfony
Comprendre le cycle d’exécution d’une requête
Créer et organiser son code pour construire une application simple
Repérer les bonnes pratiques de Symfony et de PHP en général
Intégrer les fonctionnalités avancées de PHP 5.3+ et les contraintes
de Symfony

18/03/2016
7
Cursus Symfony

18/03/2016
8
Plan du cours
Présentation
PHP avancé
Composer
Prise en main
Les bundles
Le routeur
Les contrôleurs
Le moteur de template (Twig)
Les formulaires
Les modèles
Les services
Conclusion

18/03/2016
9
Application à construire pendant la formation
• Utiliser Symfony pour développer une application-jouet : nous avons
besoin de gérer une médiathèque.
• Ceci suppose :
Un modèle riche : documents de plusieurs types, utilisateurs, emprunts,
événements,
Une interface publique + une administration
Des formats de présentation divers
Des scénarios d’utilisation variés
Des assistants nécessaires pour les différentes tâches
Des vérifications sur les informations transmises
Une politique d’URL pour les moteurs de recherche

18/03/2016
10
A qui s’adresse la formation ?
Aux développeurs
Aux architectes
Aux chefs de projets (techniques)

18/03/2016
11
Pré-requis
Une pratique de PHP
Une connaissance des bases de la Programmation Orientée Objet
Savoir configurer un serveur web, ou un environnement virtuel de type
XAMPP (Linux) ou WAMP (Windows)

18/03/2016
12
C’est parti !

18/03/2016
13
Michel CADENNES
Rappels sur PHP
Fonctionnalités
avancées

18/03/2016
14
Plan
Les différents types de classes en PHP5
Les méthodes magiques
Les espaces de noms

18/03/2016
15
Les classes abstraites
Les classes définies comme abstraites ne peuvent pas être instanciées,
et toute classe contenant au moins une méthode abstraite doit elle-
aussi être abstraite.
Les méthodes définies comme abstraites déclarent simplement la
signature de la méthode - elles ne peuvent définir son implémentation

18/03/2016
16
Les interfaces
Les interfaces objet vous permettent de créer du code qui spécifie
quelles méthodes une classe doit implémenter, sans avoir à définir
comment ces méthodes fonctionneront.

18/03/2016
17
Les traits
Les traits sont un mécanisme de réutilisation de code dans un langage à
héritage simple tel que PHP.
Un trait tente de réduire certaines limites de l'héritage simple, en autorisant
le développeur à réutiliser un certain nombre de méthodes dans des classes
indépendantes. La sémantique entre les classes et les traits, réduit la
complexité et évite les problèmes typiques de l'héritage multiple et des
Mixins.

18/03/2016
18
Les classes anonymes
Le support pour les classes anonymes a été rajouté en PHP 7.
Les classes anonymes sont utiles lorsque de simples et uniques objets
ont besoin d'être créés.

18/03/2016
19
Les méthodes magiques
Les « méthodes magiques », qui sont toujours préfixées par ‘__’ sont
utilisées par PHP pour exécuter automatiquement du code lorsqu’un
événement se produit.
__construct(), __destruct(), __call(), __callStatic(), __get(), __set(),
__isset(), __unset(), __sleep(), __wakeup(), __toString(),
__invoke(), __set_state() __clone() et __debugInfo()

18/03/2016
20
Les espaces de noms
1. Collisions de noms entre le code que vous créez, les classes, fonctions ou
constantes internes de PHP, ou celles de bibliothèques tierces.
2. La capacité de faire des alias ou de raccourcir des Noms_Extremement_Long
pour aider à la résolution du premier problème, et améliorer la lisibilité du
code.
• Dans le monde PHP, les espaces de noms sont conçus pour résoudre
deux problèmes que rencontrent les auteurs de bibliothèques et
d'applications lors de la réutilisation d'éléments tels que des classes
ou des bibliothèques de fonctions :

18/03/2016
21
Les espaces de noms
Les espaces de noms sont déclarés avec le mot-clef :
Les segments de l’espace de nom sont séparés par un ‘’
La déclaration de l’espace de nom est toujours sur la première ligne
du fichier PHP (exception faite de la directive declare)
On déclare un espace de noms par fichier source
Le libellé de l’espace de nom respecte l’arborescense des dossiers

18/03/2016
22
Les espaces de noms
Une classe est appelée avec son espace de noms :
et peut être liée à un alias qui sera ensuite utilisé dans le code :
L’espace de noms peut être retrouvé via la constante :

18/03/2016
3
Présentation
Michel CADENNES
Développeur et architecte d’information indépendant
Orientation : gestion des connaissances, intelligence artificielle, web
sémantique
Mes profils :
LinkedIn : https://www.linkedin.com/in/michel-cadennes-2a287726
Hopwork : https://www.hopwork.fr/profile/michelcadennes
Twitter : https://www.twitter.com/tchevengour
Github : https://github.com/Septentrion

18/03/2016
28
Les fonctions anonymes
Une fonction anonyme peut capturer des variables du contexte parent

18/03/2016
29
Une fonction peut également retourner une fonction anonyme :

18/03/2016
30
Les itérateurs
PHP 5 admet que des objets implémentent l’interface Iterator, et soient
donc « traversables », c’est-à-dire parcourus par une boucle.

18/03/2016
31
Les itérateurs
PHP 5 vous laisse la responsabilité d’implémenter les différentes
méthodes.
En revanche, il existe un bouquet d’itérateurs particuliers de la
bibliothèque standard pour répondre à des besoins spécifiques :

18/03/2016
32
Les générateurs
Si les intégrateurs sont des objets complexes, les générateurs sont des
fonctions que l’on peut assimiler à des « streams », particulièrement
adaptés lorsque l’on doit parcourir des grands ensembles
séquentiellement.
Un générateur utilise le mot-clef yield à la place de return

18/03/2016
33
Les générateurs
Il est possible d’envoyer des valeurs aux générateurs, pour créer des
coroutines.

18/03/2016
34
Les variables « static »
Une variable déclarée static dans le corps d’une fonction n’est évaluée
que lors du premier appel de la fonction, a une portée locale, mais fait
en sorte que le contexte d’exécution persiste à la fin de l’exécution de la
fonction.

18/03/2016
35
Les variables « static »
Les variables statiques servent notamment lors de la définition de
fonctions récursives, mais sont aussi un moyen commode d’écrire des
générateurs.

18/03/2016
36
Les fonctions d’ordre supérieur
Assez souvent négligées, il est possible d’utiliser les fonctions map,
filter et reduce sur des tableaux.
map applique une fonction à tous les éléments du tableau
filter retourne les éléments du tableau qui vérifient une certaine
fonction
reduce calcule une valeur en appliquant itérativement une fonction
à tous les éléments du tableau.
N.B. : Ces fonctions sont composables, à l’exception de
reduce, qui doit toujours être finale.

18/03/2016
37
Sur les itérables en général :
map s’applique avec la fonction iterator_apply
filter peut être appliqué au travers de la classe FilterIterator
reduce n’a pas d’équivalent.
N.B. : On atteint les limites de PHP 5 en tant que
langage de programmation moderne.

18/03/2016
38
Ce qu’on a vu
Les itérateurs
Les générateurs

18/03/2016
39
Michel CADENNES
PHP et PSR-x
Rappels sur PHP

18/03/2016
40
Plan
L’initiative PSR
Les différents niveaux de normalisation

18/03/2016
41
PSR
• PSR est une initiative d’un consortium d’acteurs de l’univers PHP (PHP
Framework Interop Group PHP-FIG) pour formaliser des conventions
d’écriture permettant la réutilisabilité du code entre les plate-formes.
• A ce jour, il y a 7 recommandations et d’autres sont en cours de
rédaction

18/03/2016
42
PSR-4
• PSR-4 (ex PSR-0) est sans doute la recommandation la plus importante
puisqu’elle précise comment se fait l’autoloading des classes dans une
application PHP

18/03/2016
43
PSR-1
• PSR-1 liste des conventions d’écriture de base, notamment :
Les fichiers PHP doivent s’abstenir de tout effet de bord, en
particulier par le biais de require, include, echo, global, etc.
Les noms de classes s’écrivent en « capitales attractives », i.e.
l’initiale est une majuscule
Les noms de méthodes s’écrivent en « camelCase » i.e. l’initiale est
une minuscule

18/03/2016
44
PSR-2
• PSR-2 précise les conventions d’écriture du code. Elle a pour vocation de
rendre le code PHP plus lisible. Notamment :
Les indentations utilisent des espaces et non des tabs
Toutes les propriétés et les méthodes doivent avoir une visibilité
déclarée
La parenthèse ouvrante du corps des méthodes est placée sur la
ligne suivante

18/03/2016
45
PSR-3
• PSR-3 contient un certain nombre de règles à propos des journaux de
longs des applications. En particulier, elle définit les niveaux d’alerte et
ce que devraient être les messages et la prise en compte du contexte
• PSR-3 fournit une classe abstraite : AbstractLogger

18/03/2016
46
PSR-7
• PSR-7 liste des recommandations relatives aux messages HTTP.
Spécification d’interfaces pour les requêtes et les réponses
Les noms d’entêtes HTTP sont insensibles à la casse
Il est fourni une méthode pour gérer les entêtes à valeurs multiples
L’entête Host doit être fourni
Il devrait être fourni une interface pour des streams en cas de
contenu très volumineux

18/03/2016
47
Drafts
• D’autres recommandations sont en cours d’écriture. Notamment :
PSR-5 sur la documentation
PSR-11 sur l’injection de dépendances
PSR-12, qui devrait synthétiser PSR-1 & 2

18/03/2016
48
Conclusion
Dans les applications web, l’architecture « réelle » est souvent plus
proche d’une architecture 4-tier (4 étages) que d’un MVC standard
Cette architecture n’est pas hégémonique : Drupal n’est pas conçu ainsi
et se rapprocherait plutôt d’une architecture 3-tier
Ces modèles sont sans doute amenés à évoluer avec la tendance aux
« clients lourds » de bibliothèques JavaScript (Angular, React) capables
de prendre en charge une grande partie du traitement, et l’arrivée des
WebComponents

18/03/2016
49
Ce qu’on a vu
L’initiative PSR
Les différents niveaux de normalisation

18/03/2016
50
Michel CADENNES
PHP et MVC
Rappels sur PHP

18/03/2016
51
Plan
L’architecture MVC
Adéquation aux applications web

18/03/2016
52
Architecture
M = Modèle
V = Vue
C = Contrôleur
• Une architecture pour les applications web

18/03/2016
53
Le contrôleur
Le contrôleur est chargé de gérer les interactions entre l’utilisateur et le
modèle.
Il reçoit les requêtes
Il traduit la requête, soit en la transmettant au modèle, soit en
demandant à la vue une mise à jour de l’affichage
Il peut implémenter des fonctions de mise à jour de la vue

18/03/2016
54
Le modèle
Le modèle contient toutes les données relatives à l’application et toutes
les méthodes pour y accéder.
Il enregistre les vues et les contrôleurs qui doivent accéder aux données
Il notifie les composants des modifications

18/03/2016
55
La vue
La vue est responsable de la présentation des données du modèle dans
l’interface utilisateur
Elle crée et initialise les contrôleurs
Elle consulte les données du modèle
Elle enregistre les actions de l’utilisateur et les transmet au contrôleur

18/03/2016
56
Avantages
L’architecture MVC schématise des rapports très clairs entre les
différents composants de l’application
Son fonctionnement n’est pas hiérarchique, ce qui autorise les vues à
envoyer des requêtes directement au modèle (cf. Doctrine et Twig)
Elle facilite le partage des tâches en matière de développement (entre
les différents métiers)
Les relations entre les composants sont à priori asynchrones.

18/03/2016
57
Limites
MVC est surtout conçu pour gérer le rafraîchissement simultané de
plusieurs vues, ce qui n’est pas le cas des applications web (peut-être à
venir avec les WebSockets)
Dans les applications web, il y a une ambiguïté sur les vues qui sont à la
fois des pages et le code exécuté par le navigateur et le code côté
serveur chargé de composer l’interface (les moteurs de template)
Une approche moderne de contrôleurs minces laisse de côté toute une
partie du code qui ne se retrouve pas non plus dans le modèle (i.e. les
services dans Symfony)
L’interprétation de MVC varie énormément entre les implémentations

18/03/2016
58
Conclusion
Dans les applications web, l’architecture « réelle » est souvent plus
proche d’une architecture 4-tier (4 étages) que d’un MVC standard
Cette architecture n’est pas hégémonique : Drupal n’est pas conçu ainsi
et se rapprocherait plutôt d’une architecture 3-tier
Ces modèles sont sans doute amenés à évoluer avec la tendance aux
« clients lourds » de bibliothèques JavaScript (Angular, React) capables
de prendre ne charge une grande partie du traitement, et l’arrivée des
WebComponents

18/03/2016
59
Michel CADENNES
Composer
Gestion de dépendances
pour PHP

18/03/2016
60
Plan
Qu’est-ce que Composer ?
Installer Composer
Configuration de projet dans composer.json
La section « require »
Les contraintes sur les versions
Gestion de l’autolaoad

18/03/2016
61
Composer
Introduction à la gestion de paquets

18/03/2016
62
Qu’est-ce que Composer ?
Composer est le gestionnaire de paquets et de dépendances pour PHP
Est inspiré de npm (NodeJS) et bundler (Ruby)
Est destiné à gérer l’installation de ressources par projet (et non
globalement comme get-apt, pip ou gem)
Vérifie les dépendances récursivement

18/03/2016
63
Installer Composer
• Installer Composer se fait par la ligne de commande (Linux | OS X) :
• Si vous voulez rendre Composer exécutable globalement, il faut
ensuite le déplacer dans un répertoire inclus dans $PATH
curl -sS https://getcomposer.org/installer | php
mv composer.phar /usr/local/bin/composer

18/03/2016
64
Utiliser Composer
• Une fois Composer installé, il suffit de l’appeler depuis la ligne de
commande :
• L’initialisation d’un projet PHP se fait par la commande :
composer —version
composer install

18/03/2016
65
Configurer un projet
Le schéma de composer.json

18/03/2016
66
composer.json
• Pour initialiser un projet, Composer se sert d’un fichier de configuration
nommé composer.json
• Ce fichier décrit toutes les dépendances sur lesquelles repose votre
projet, ainsi que diverses méta-données.
• La section principale trouvé dans ce fichier est : require, qui indique
quelles sont les ressources à installer

18/03/2016
73
Ce qu’on a vu
Le rôle de Composer dans les projets PHP
Installer Composer
Utiliser Composer via le shell
Créer un fichier de configuration simple

18/03/2016
74
Michel CADENNES
Composer
Options et commandes
de Composer

18/03/2016
75
Plan
Les options du fichier composer.json
Les commandes principales
Les options de configuration
Les dépôts de paquets

18/03/2016
76
Les options de Composer.son
Unfichier de configuration enrichi

18/03/2016
77
Options de composer.json
Le schéma de composer.json comporte encore d’autres sections :
pour identifier l’application
pour spécifier le niveau de stabilité d’un paquet
pour identifier les dépôts sources
pour identifier des scripts à exécuter après Composer
pour passer des des informations annexes
pour ajouter des paquets suggérés ou requis en phase développement

18/03/2016
78
Options de composer .json
Certaines options ne peuvent se trouver qu’à la racine du fichier de
configuration dont :
scripts, config, minimum-stability, require-dev

18/03/2016
79
Les commandes
Piloter Composer depuis la ligne de commande

18/03/2016
80
Les commandes de Composer
• Outre install, Composer possède une liste de commandes pour divers
usages.
• Par exemple :
init pour créer de manière interactive le fichier composer.json
update pour mettre à jour les paquets
remove pour désinstaller un paquet
search pour chercher un paquet dans un dépôt
suggests pour lister les dépendances suggérées par les paquets
validate pour valider le fichier composer.json
self-update pour mettre à jour Composer

18/03/2016
81
Les options de configuration
• Le schéma de composer.json comporte une section « config » qui
permet de paramétrer Composer.
• Entre autres :
use-include-path autoload inspectant de PATH de PHP
preferred-install source ou dist
platfom choisir une version de PHP
search pour chercher un paquet dans un dépôt
vendor-dir répertoire pour les paquets tiers
notify-on-install notifier le dépôt de l’installation du paquet

18/03/2016
82
Les dépôts

18/03/2016
83
Les dépôts
Composer repose principalement sur le dépôt Packagist
http://www.packagist.org
On peut aussi trouver des ressources ici :
http://www.phppackages.org
Et ici pour Symfony en particulier :
http://knpbundles.com/

18/03/2016
84
Les dépôts
• Paramétrer les sources d’où tirer les paquets se fait dans la section
‘repositories’.
• En particulier, il est possible d’utiliser Github ou PEAR comme sources.

18/03/2016
85
Les dépôts : PEAR
• Un exemple PEAR, les paquets sont préfixés par ‘pear-<channel>’ :

18/03/2016
86
Les dépôts : composer
• Composer peut aussi importer des ressources indirectement, en allant
chercher un autre fichier de déclaration packages.json qui doit être
présent sur le dépôt.

18/03/2016
87
Ce qu’on a vu
Configurer Composer
Les diverses commandes pour maintenir un projet avec Composer
Où trouver des dépôts

18/03/2016
88
Pour aller plus loin
La documentation de Composer
https://getcomposer.org/doc/

18/03/2016
89
Michel CADENNES
Symfony
Installation
de Symfony 3

18/03/2016
90
Plan
Installer Symfony
Tester la configuration serveur
Lancer le serveur intégré
La première page
Les outils du développeur
La barre d’outils web
Le profileur

18/03/2016
91
Les pré-requis pour faire fonctionner Symfony 3
PHP 5.5.9+
Support de JSON
Support de ctype
php.ini doit avoir une option date.timezone définie
(une erreur extrêmement courante)

18/03/2016
92
Installer Symfony
Trois techniques pour installer Symfony :
Télécharger l’archive depuis Github
Utiliser l’installeur symfony
Utiliser Composer

18/03/2016
93
Installer Symfony : Téléchargement
La méthode la plus directe
Installe tout sans distinction

18/03/2016
94
Installer Symfony : symfony
Nécessite d’installer un script (une fois pour toute)
Permet de systématiser les installations
Offre davantage de souplesse dans la création de projets
La méthode recommandée par SensioLabs

18/03/2016
95
Installer Symfony : Composer
Nécessite d’installer Composer
Permet d’installer sélectivement des composants de Symfony
Permet d’installer simultanément des bibliothèques tierces
Offre un outil complet pour la gestion des projets

18/03/2016
96
Lancer Symfony
• Une fois tous les fichiers installés, il est possible de démarrer Symfony
de manière autonome en utilisant le serveur HTTP intégré
(celui de PHP, en fait)
php bin/console server:start
• Pour l’arrêter :
php bin/console server:stop

18/03/2016
97
La première page d’un projet Symfony

18/03/2016
99
Le profileur
• Par la barre d’outils, le développeur a accès
à des données de profilage très détaillées

18/03/2016
100
Ce qu’on a vu
Installer le code de Symfony
Tester le serveur
Démarrer simplement Symfony
Explorer les données fournies par le profileur

18/03/2016
101
Michel CADENNES
Symfony
Architecture
d’un projet Symfony

18/03/2016
102
Plan
Architecture d’un projet Symfony
Symfony comme boîte à outils
Les fichiers de configuration
Les formats de fichiers dans Symfony
Introduction aux environnements

18/03/2016
103
Tour d’horizon de l’installation
• Les répertoires à la racine de votre projet Symfony :

18/03/2016
104
Symfony comme boîte à outils
Assetic
ClassLoader
Config
Console
CssSelector
Debug
DependancyInjection
DomCrawler
EventDispatcher
ExpressionLanguage
FileSystem
Finder
Form
HttpFoudation
HttpKernet
Intl
OptionsResolver
Process
PropertyAccess
Routing
Security
Serializer
Stopwatch
Templating
Translation
VarDumper
Yaml
• Symfony repose sur une collection de composants (Components), qui assurent
les différentes fonctions du noyau du framework

18/03/2016
105
Les fichiers de configuration
Le répertoire app/config contient toutes les données globales de
configuration du projet Symfony

18/03/2016
106
Les formats de configuration
D’une manière générale, Symfony laisse beaucoup de choix au développeur. Les
quatre formats a priori reconnus sont :
YAML : un format simple, léger et aisément compréhensible par des non-
développeurs
XML : un format robuste, reconnu par PHP et adapté aux manipulations par
les machines (XSLT, Dom, etc.)
Annotations : A l’instar de PHPDoc, permettent d’intégrer les configurations
directement dans les fichiers sources
PHP : le langage natif

18/03/2016
107
Les environnements
Un environnement est globalement une configuration de Symfony.
Trois environnements sont définis par défaut :
prod : ce que voient les utilisateurs du site
dev : ce que voient les développeurs du site
test : ce qui est utilisé pour les jeux de tests

18/03/2016
108
Ce qu’on a vu
L’organisation du système de fichiers de Symfony
Les composants qui constituent la boîte à outils de Symfony
La confguration globale de l’application
Les types de formats de fichiers supportés par Symfony
Comment tirer parti des environnements

18/03/2016
109
Michel CADENNES
Symfony
De Symfony 2 à Symfony 3

18/03/2016
110
Plan
Quelques changements
Une règle : ne pas casser la rétro-compatibilité
Migrer d’une version 2.x à 3.0
Quelle version utiliser ?

18/03/2016
111
Tour d’horizon de l’installation
• De nouveaux répertoires :
/var
/tests

18/03/2016
112
Liste des modifications
Les listes des modifications apportées au code de Symfony est
disponible dans le fichier :
/vendor/symfony/symfony/UPGRADE-3.0.md

18/03/2016
113
La rétro-compatibilité
La version 3.0 enlève toutes les fonctions devenues obsolètes.
Celles-ci vont donc provoquer des erreurs si elles restent dans le code

18/03/2016
114
Utiliser le profiteur
• Le profileur affiche des warnings pour toutes les fonctions obsolètes,
depuis la version 2.5

18/03/2016
115
Migrer de la version 2 à la version 3
Installer une version 2.8
Rechercher le code obsolète au travers du profileur
Eventuellement rechercher le code obsolète avec PHPUnit (et le bridge
développé par Symfony)
Modifier le code pour le rendre up-to-date
Basculer toute la base de code propre vers l’installation 3.0

18/03/2016
116
LTS
La version 3.0 ne sera pas une version à « support à long terme » (Long
Time Support — LTS)
La première version LTS pour Symfony 2 était le 2.3 (obsolète mi-2016),
puis la 2.7 et 2.8
La première version LTS pour Symfony 3 sera la 3.4 prévue mi-2017
La version 3.0 et la version 2.8 sont presque simultanées
La version 3.0 n’ajoute que très peu de fonctions qui ne seraient pas
compatibles avec la version 2.8

18/03/2016
117
Ce qu’on a vu
Les changements « structurels » dans le code de Symfony 3
Comment trouver les fonctions obsolètes
Comment s’assurer que le code de l’application est compatible avec
Symfony 3
Les raisons d’utiliser une version plutôt qu’une autre

18/03/2016
118
Michel CADENNES
Les bundles
Créer des modules fonctionnels
pour Symfony

18/03/2016
119
Plan
Qu’est-ce qu’un « bundle » ?
Les bundles tiers
Les bundles de l’application
Création d’un bundle
Architecture d’un bundle
Installer un bundle tiers
Où trouver des ressources ?
Hériter d’un bundle parent
Bonnes pratiques pour les bundles

18/03/2016
120
Qu’est-ce qu’un bundle ?
Un « bundle », c’est littéralement un paquet, voire un fagot ou une
botte.
C’est donc l’idée d’un certain nombre de ressources qui sont liées
ensemble pour créer une unité fonctionnelle.
En l’occurrence, un bundle contient tout ce qu’il faut de l’architecture
MVC (et plus) pour construire une application au-dessus du noyau de
Symfony
Les bundles sont des unités architecturales et non techniques. La
décomposition de l’application en modules fonctionnels est donc un
choix qui n’est pas unique

18/03/2016
121
Les bundles tiers
• Les bundles tiers sont hébergés dans le répertoire :
• Il n’est pas conseillé de les modifier ou d’installer son propre code dans
ce dossier, sauf si vous construisez des bibliothèques génériques.
• Les bundles tiers comportent souvent des moyens pour étendre leurs
fonctionnalités (comme des factories, ou des classes abstraites)

18/03/2016
122
Les bundles de l’application
• Les bundles spécifiques à l’application sont hébergés (par défaut) dans le
répertoire :
• Il est possible de créer son propre dossier de bundles. Néanmoins, cela
n’est pas une pratique courante et a un intérêt plutôt limité.

18/03/2016
123
Créer un bundle
• Le moyen le plus simple de créer un bundle est de passer par la ligne de
commande
• Symfony entre alors dans une procédure interactive qui vous permet de
paramétrer votre bundle.
• Il est évidemment possible de créer manuellement un bundle ou de
copier simplement un dossier existant dans le dossier /src

18/03/2016
124
Créer un bundle
• La procédure via la console Symfony a l’avantage de modifier
l’application pour que le bundle soit immédiatement actif.
• Cela veut dire, mettre à jour deux fichiers :

18/03/2016
126
Installer un bundle tiers
• Pour cela, la meilleur méthode est d’utiliser Composer.
• Puisque Symfony respecte les conventions PSR-x, on peut utiliser les
packages qui sont sur ces sites :
http://symfohub.com/bundles
http://www.packagist.com
http://www.knpbundles.com

18/03/2016
127
Choisir un bundle
• Il existe maintenant plusieurs milliers de bundles pour Symfony.
Quelques critères :
Les followers sur GitHub
Un bon README
Intègre Travis CI
Reconnu par Composer
Maintenu récemment
Nombre de dépendances
https://scrutinizer-ci.com/

18/03/2016
128
Bonnes pratiques
SensioLabs recommande d’utiliser un seul bundle (AppBundle) pour le
code métier — à discuter
Il est possible de créer des espaces de noms en dehors des bundles
pour du code métier (dans /src) — mais les bundles doivent rester
privilégiés
Les standards PSR-1 et PSR-2 devraient toujours être respectés
Le bundle devait fournir des jeux de tests — pas abordés ici

18/03/2016
129
Et maintenant ?
• Comme le dit Symfony, votre bundle est prêt à être utilisé.
• Reste une possibilité : déclarer un bundle parent dont vous pourrez
hériter. Pour cela, il faut juste modifier le fichier :

18/03/2016
130
Ce qu’on a vu
Ce que c’est qu’un bundle et où trouver l’information
Comment créer un bundle
Comment installer des bundles tiers
Les règles à respecter pour organiser un bundle
Comment créer une hiérarchie de bundles

18/03/2016
131
Michel CADENNES
Le routage
Introduction
au routage

18/03/2016
132
Plan
Rappels sur le routage
Intégration par défaut des routes dans Symfony
Personnaliser la configuration
Différentes façons de déclarer les routes
Exemples
Avantages et inconvénients
Relation entre route et contrôleur

18/03/2016
133
Le Routage dans Symfony

18/03/2016
134
Les routes
Les routes sont un élément essentiel des applications web.
Elles doivent être signifiantes pour l’utilisateur
Elles doivent être dénuées d’ambiguïté pour l’analyser de l’application
Elles doivent permettre une bonne indexation par les moteurs de recherche
Elles doivent être suffisamment simples pour être transmises
Toute application web doit avoir une politique d’URL stricte et stable

18/03/2016
135
Les URL
Une URL se décompose en :
un protocole => http
un nom de domaine => www.exemple.com
un port => 8080
un chemin => /blog/article/ (les slashes découpent des segments)
un nom de ressource => index.html, premier-billet, image.jpg
des options => ?x=hello&y=25
un fragment => #chapitre-3

18/03/2016
136
Les URL perçues par Symfony
Une URL se décompose en :
protocole => fichier de routage
nom de domaine => Apache
port => Apache
chemin => fichier de routage
nom de ressource => fichier de routage
options => contrôleur
fragment => navigateur

18/03/2016
137
La réécriture d’URL
Dans Symfony, le « contrôleur principal », ou point d’entrée de
l’application est en fait multiple, en fonction de l’environnement.
L’analyseur d’URL PHP de Symfony est maintenant considéré comme
quasiment aussi efficace que l’analyseur d’Apache

18/03/2016
138
Le composant Routing
Routing est un des composants du noyau de Symfony. Il est en charge, en
particulier de :
Gérer des collections de routes
Déterminer les contextes des requêtes
Apparier une URL et une route
Forger des URL valides en fonction d’une route

18/03/2016
139
Les formats de fichiers de configuration
Symfony laisse le développeur choisir son propre format de fichier pour les
configurations. Il y a 4 possibilités :
YAML // Très simple et concis
XML // Très robuste
Annotations // Permettent d’embarquer tout dans un seul fichier
PHP // Ne nécessite aucun traitement syntaxique

18/03/2016
140
YAML (Exemple)
N.B. : Attention aux espaces !!

18/03/2016
141
XML (Exemple)
N.B : Syntaxe un peu fastidieuse (néanmoins la solution la plus sûre,
employée tout au long de ce cours)

18/03/2016
143
PHP (Exemple)
N.B. : Non déclaratif

18/03/2016
144
Routeur et contrôleur
Sur le web, les routes sont des API de votre application. Elles en sont
le versant syntaxique. Le versant opérationnel, lié de manière
indissoluble est le contrôleur.
A chaque route doit correspondre une action de contrôleur :
Toutes les méthodes représentant des actions liées à des routes doivent
être suffixées par le mot-clef Action.
public function operationAction (…)

18/03/2016
145
Ce qu’on a vu
Dans cette vidéo, nous avons vu le principe du routage :
Le mécanisme repose sur un des composants de Symfony : Routing
Comment Symfony configure par défaut le mécanisme de routage
Les différentes syntaxes permettant de configurer les routes (et pas
qu’elles)
Comment est assurée la liaison entre la structure de la route et le
traitement de la requête

18/03/2016
146
Dans les prochaines sessions, nous verrons toutes les possibilités offertes
pour décrire les routes et les bonnes pratiques pour gérer ses configurations.

18/03/2016
147
Plan
Michel CADDENNES
Configuration
des routes
Le routage

18/03/2016
148
Plan
Création d’une route simple
Les éléments essentiels : nom & motif du chemin
L’élément <default />
Ajouter des éléments variables dans une route
Eléments requis ou éléments optionnels
Ajouter des contraintes aux variables
Déclarer des méthodes HTTP
Déclarer un hôte HTTP
Les variables spéciales

18/03/2016
149
Caractéristiques d’une route
Une route est principalement définie par deux propriétés clefs :
id : un identifiant unique qui permet à l’application d’accéder à la route
ex : bundle_action
path : le schéma de l’URL qui permettra d’analyser, par pattern-matching, la
requête du navigateur
ex : /blog/premier-billet

18/03/2016
150
La propriété default
Une autre propriété essentielle des routes est la propriété default, qui
permet de préciser la valeur des paramètres donnés pour une route.
En particulier, une de ces propriétés est le nom du contrôleur associé
à la route.
_controller => <nomDuBundle>:<nomDuControleur>:<nomDeAction>

18/03/2016
151
Des variables dans le schéma de route
La propriété path contient des schémas d’URL.
On souhaite donc que toutes celles répondant à un schéma soient
capturées par la même règle.
Pour ça, on introduit des variables dans le schéma :
Les noms des variables doivent se retrouver comme arguments de la
méthode du contrôleur
path => /article/{mois}/{jour}/{titre}

18/03/2016
152
Des variables dans le schéma de route
Par défaut les variables sont requises.
On peut les rendre optionnelles en ajoutant une entrée dans la liste des
default.
Une autre technique (moins lisible) consiste à donner une valeur par
défaut directement dans la signature de la méthode du contrôleur
default => mois = 1

18/03/2016
153
Des contraintes sur les valeurs
Il est également possible de poser des contraintes sur les valeurs des
segments de la route, grâce à des expressions régulières. On se septuor
cela de la propriété requirement.
requirement => mois : d{2} // Les mois sont sur deux chiffres
requirement => titre : [a-w-]+ // les titres ssont composés de lettres et de
tirets

18/03/2016
154
Des contraintes sur les requêtes
Une autre manière de distinguer les routes est de prendre en compte la
méthode HTTP de la requête.
On peut ainsi ajouter une propriété methods pour le spécifier :
methods => GET | POST

18/03/2016
155
Des contraintes sur les requêtes
Enfin, il est possible de filtrer les requêtes en fonction du domaine
auquel on souhaite accéder.
Cela est possible par le biais de la propriété host.
host => m.domaine.tld
host => {sous_domaine}.domaine.tld // avec une variable

18/03/2016
156
Des variables spéciales
Hormis _controller, les routes reconnaissent deux variables spéciales
(toujours préfixées pas le caractère _ )
_format => indique le format de la réponse : html, json, xml, etc.
_locale => indique la langue associée à la parce demandée

18/03/2016
157
Ce qu’on a vu
Dans cette session, nous nous sommes plus précisément attachés à la
syntaxe des routes.
Comprendre le fonctionnement des motifs pour les routes
Ajouter des contraintes et des options pour aiguiller le routeur de
Symfony
Ajouter des informations pour envoyer des réponses appropriées au
navigateur

18/03/2016
158
Dans la dernière session, ajouter quelques astuces pour gérer efficacement
les routes et les implications sur une politique d’URL.

18/03/2016
159
Plan
Michel CADDENNES
Gestion des routes
Le routage

18/03/2016
160
Plan
Importer des routes externes
Règle d’application des routes
Découper ses fichiers de routage
Préfixer les routes d’un ensemble importé
Reconfigurer la racine des routes
Utiliser HTTPS
Déboguer les routes via la ligne de commande

18/03/2016
161
Importer des routes
• Par défaut, les routes se trouvent dans les fichiers routing.<fmt> des
bundles ou dans le fichier routing.yml de l’application.
• Il est toutefois recommandé de diviser les fichiers de configuration si ceux-ci
deviennent trop volumineux. A ce moment, on peut utiliser la directive
import pour indiquer des ressources externes.

18/03/2016
162
Règle d’application
• Les schémas de routes s’appliquent selon la règle : « premier trouvé,
premier servi ».
• De ce fait, il est très important :
de bien classer les routes
d’avoir une politique de schémas claire et lisible
d’utiliser les ressources syntaxiques pour aider les moteurs à
discriminer correctement les URLs qu’ils reçoivent

18/03/2016
163
Découper les fichiers
• Par défaut, les routes se trouvent dans les fichiers routing.<fmt> des
bundles ou dans le fichier routing.yml de l’application.
• Il est toutefois recommandé de diviser les fichiers de configuration si ceux-ci
deviennent trop volumineux. A ce moment, on peut utiliser la directive
import pour indiquer des ressources externes.

18/03/2016
164
Préfixer les routes
• Il est souvent de bonne pratique d’associer à tout un ensemble de routes un
même segment.
/blog // Toutes les URL des billets de blog commencent par ce
segment
• Il est possible d’indiquer cela si un ensemble de routes est déclaré comme
ressource externe.

18/03/2016
165
Reconfigurer la racine des routes
• Par défaut, la racine se trouve, comme nous l’avons vu dans les fichier
routing.yml associé à l’application.
• Mais ceci peut être changé dans le fichier config.yml, soit pour changer
l’emplacement de la racine, soit pour en changer le format, par exemple

18/03/2016
166
Tester les routes
• Grâce à la ligne de commande, il est possible de tester que les routes
configurées sont véritablement accessibles par le routeur.
php bin/console router:debug

18/03/2016
167
Forcer la sécurité des requêtes
Parmi les options avancées, il est aussi possible de préciser le protocole utilisé :
schemes =>http | https

18/03/2016
168
Ce qu’on a vu
Dans cette session, nous avons exploré quelques considérations
méthodologiques sur la manipulation des routes dans Symfony :
L’organisation des fichiers de routage
Comment éviter les conflits dans votre bibliothèque de routes
Une introduction aux problèmes de politique d’URL

18/03/2016
169
D’autres possibilités sont offertes par le composant Routing, qui sort de
l’objet de ce cours, comme par exemple :
Configurer plus efficacement les routes grâce à des services
Créer des loaders ad hoc créer des routes de manière dynamique
Passer des paramètres supplémentaires au contrôleur

18/03/2016
170
Michel CADENNES
Les contrôleurs
Au cœur du cycle
d’exécution

18/03/2016
171
Plan
Introduction
Créer une classe de contrôleur
Où placer les classes de contrôleur ?
Précisions syntaxiques
Créer une action en lien avec une route
Le cycle d’exécution
La classe Request
La classe Response

18/03/2016
172
Créer une classe de contrôleurs
• Une classe de contrôleur est une sous classe de la classe Controller :
• Implémenter la classe Controller permet d’avoir accès à toute une série de
raccourcis syntaxiques, mais n’est pas obligatoire.Dans certains cas, on
peut même utiliser la classe ConainerAware dont Controller hérite.

18/03/2016
173
Créer une classe de contrôleurs
• Le contrôleur a pour tâche spécifique de gérer la réponse à
la requête. Celle-ci peut être généralement de deux types :
• un contenu envoyé au navigateur ou
• une redirection

18/03/2016
174
Où placer les contrôleurs ?
Les classes de contrôleurs sont placées dans le dossier Controller du
bundle correspondant.
A l’intérieur du dossier, il est possible de créer des sous-dossiers pour
classer ses contrôleurs
Lorsque l’on crée un bundle, une classe est immédiatement créée, au
nom de DefaultController, mais son existence n’est pas du tout
obligatoire.

18/03/2016
175
Règles syntaxiques
Les classes doivent porter le même nom, avec la même casse, que le
fichier qui les contient
Les classes sont toujours suffixées par -Controller
Grâce aux espaces de noms, des classes dans des bundles différents
peuvent porter le même nom

18/03/2016
176
La signature du contrôleur
Un contrôleur est une méthode de la classe de contrôleurs
Le suffixe -Action indique que cette méthode est liée à une route.
La signature reprend la liste des variables définies dans la route, sans ordre
précis. des valeurs par défaut peuvent être attachées aux arguments.

18/03/2016
177
La classe Request
• La classe Request a pour principale fonction de fournir des accesseurs pour
tous les paramètres gérés habituellement par PHP dans les variables super-
globales.

18/03/2016
178
La classe Response
• La classe Response a la responsabilité de gérer tous les paramètres de la
réponse :
• Les entêtes sont généralement associés séparément :

18/03/2016
179
Créer un contrôleur
• Le contrôleur le plus simple aurait une forme telle que celle-ci :
• Ne faisant que renvoyer du code HTML au navigateur. Ici tous les
entêtes liés à la réponse sont pris en charge automatiquement.

18/03/2016
180
Créer un contrôleur
• Dans le cas où la requête est intégrée à la signature du contrôleur, il faut
faire attention d’utiliser la découverte de type (type hinting) pour
permettre à Symfony de repérer l’argument correspondant
• Tout contrôleur doit envoyer une réponse, sinon une erreur est
déclenchée.

18/03/2016
181
Ce qu’on a vu
Comment construire une classe de contrôleurs
Comment Symfony utilise les contrôleurs dans son cycle d’exécution
Le fonctionnement de la classe Request
Le fonctionnement de la classe Response
Comment créer un contrôleur simple

18/03/2016
182
• La prochaine étape consiste à écrire des contrôleurs pour le monde
réel.
• Vous pouvez consulter la documentation de l’API Symfony pour avoir
plus de détails sur les classes Controller, Request et Response
http://api.symfony.com/3.0

18/03/2016
183
Michel CADENNES
Les contrôleurs
Les outils du contrôleur

18/03/2016
184
Plan
Récupérer les paramètres de la requête HTTP
Options de la classe Response
Autres possibilités : redirect, redirectToRoute, forward
Gestion des erreurs et page 404
Accéder à des « services »
Gestion de la session
Envoyer des messages Flash
Bonnes pratiques pour les contrôleurs
Des actions maigres et des services

18/03/2016
185
Utiliser la classe Request
La classe Request permet d’explorer et de manipuler les requêtes HTTP,
en offrant une interface avec les variables superglobales.
Exemples :

18/03/2016
187
Types de réponses
Une réponse peut être un contenu envoyé au navigateur, mais également
une redirection. Symfony offre trois possibilités :

18/03/2016
188
Gestion des erreurs
En modifiant le code d’erreur de la réponse
En déclenchant une exception
Les erreurs peuvent se gérer de deux manières différentes :

18/03/2016
189
Pages d'erreurs
Lorsque qu’une erreur se produit, Symfony utilise un gabarit d’affichage
particulier
Dans l’environnement de production, il affiche juste un
message d’erreur
Dans l’environnement de développement, il affiche la trace
complète de l’erreur

18/03/2016
190
Pages d'erreurs
Il est possible de changer l’aspect de ces pages en modifiant (ou créant)
le gabarit correspondant à l’erreur dans le dossier

18/03/2016
191
Gestion des sessions
La classe Request offre un accès à une session utilisateur qui encapsule la
superglobale $_SESSION

18/03/2016
192
Les messages Flash
Les messages Flash sont des messages destinés à s’afficher une seule fois
dans le navigateur. Ils peuvent être stockés dans un objet de type Bag
(FlashBag) et s’effacent automatiquement une fois utilisés.
Les messages Flash peuvent être triés par catégories et sont stockés dans
la session utilisateur.

18/03/2016
194
Bonnes pratiques
Créer une classe de contrôleur par fonctionnalité (services web, URL
publiques, administration, rétro-compatibilité, etc.)
Organiser des groupes de contrôleurs par dossier
Ecrire des contrôleurs minces
Ne pas utiliser les contrôleurs pour abriter du code métier ou du code
lié à la présentation

18/03/2016
195
Ce qu’on a vu
Les détails des classes Request et Response
La gestion des erreurs HTTP par les contrôleurs
et la personnalisation des pages d’erreur
La gestion des sessions
L’intégration de messages de notification
Le lien avec les fichiers de configuration
… et quelques conseils d’organisation

18/03/2016
196
Les rôles des contrôleurs est à la fois essentiel et circonscris.
Ils peuvent se retrouver dans d’autres contextes comme des vues ou des
services.
http://api.symfony.com/3.0

18/03/2016
197
Michel CADENNES
Twig
Introduction aux vues
Michel Cadennes

18/03/2016
198
Plan
Qu’est-ce que Twig ?
Pourquoi utiliser Twig ?
Les bases de la syntaxe
Variables
Directives
Filtres et fonctions
Commentaires
Héritage
Conclusion

18/03/2016
199
Qu’est-ce que Twig ?
Twig est le « moteur de template » intégré à Symfony
C’est un pseudo-langage de programmation
Il sert à afficher les vues de l’architecture MVC
Un composant développé par Sensio Labs pour Symfony, mais utilisé
par d’autres plate-formes PHP
Il est très bien intégré avec Doctrine

18/03/2016
200
Pourquoi utiliser Twig ?
Il permet de créer des hiérarchies de templates
C’est une couche d’abstraction
Il fait le lien avec le modèle et l’ORM (par défaut Doctrine)
Il est très facilement extensible
Et pourquoi pas directement PHP ?
une meilleure interface avec contrôleurs
une syntaxe plus « intuitive »
le mécanisme de cache

18/03/2016
201
La syntaxe : les variables
Les variables

18/03/2016
202
La syntaxe : Les directives
Les directives

18/03/2016
203
La syntaxe : les commentaires
Les commentaires

18/03/2016
204
La syntaxe : filtres et fonctions
Les filtres et les fonctions

18/03/2016
205
La syntaxe : hiérarchiser les squelettes
L’héritage
N.B : la fonction parent() permet de conserver le contenu du parent

18/03/2016
211
Embarquer un contrôleur
• Il est également possible de faire appel à un contrôleur depuis une
vue :

18/03/2016
212
Charger une vue de manière asynchrone
• Symfony autorise le chargement asynchrone, qui peut être très utile
lorsque les pages sont lourdes :
• Cette fonctionnalité oblige l’inclusion du script hinclude.js dans la
page HTML

18/03/2016
213
Charger une vue de manière asynchrone
Il faut modifier la configuration de Symfony pour pouvoir exécuter de
manière asynchrone des sous-contrôleurs
Il est possible d’associer un affichage par défaut en attendant que le
fragment soit chargé
Cet affichage par défaut peut être défini pour toute l’application

18/03/2016
214
Les liens
• Les liens internes peuvent avantageusement déclarés par le nom de
leur route avec les directives path et url :

18/03/2016
215
Variables globales
• Enfin, les squelettes ont directement accès à quelques variables
globales de l’application :

18/03/2016
216
Intégrer des ressources

18/03/2016
217
Les ressources
• L’inclusion de fichiers de ressources se fait par la directive asset, donc
le but principal est d’assurer une meilleur portabilité des applications.

18/03/2016
219
Présentation d’Assetic
Assetic est un composant tiers dont le but est de gérer les fichiers de
ressources des applications PHP.
Le principe est repris de la bibliothèque webassets, développée pour
Python
Cette formation n’entrera pas dans les détails d’Assetic mais entend
juste présenter ses possibilités

18/03/2016
220
Fonctionnalités d’Assetic
Minifier des fichiers (javascript, CSS)
Rassembler plusieurs fichiers dans un seul pour diminuer les requêtes
Compiler des fichiers CSS à partir de sources SASS
Optimiser des images
Appliquer des « filtres » à des fichiers de ressources
Mettre en cache des ressources

18/03/2016
221
Fonctionnalités d’Assetic
• Assetic peut nécessiter l’installation de ressources système pour
fonctionner, par exemple :
SASS (Ruby) pour activer le pré-processeur CSS
JpegOptim pour l’optimisation des images

18/03/2016
222
Ce qu’on a vu
Modulariser les squelettes en :
incluant des squelettes externes
calculant des contenus en faisant appel à un contrôleur
permettant le chargement asynchrone de blocs
Gérer les ressources (js, css, images)
Intégrer correctement des liens internes

18/03/2016
223
Michel CADENNES
Twig
Etendre Twig
Michel CADENNES

18/03/2016
224
Plan
Les macros
Les filtres et les fonctions
La classe Twig_Extension
Créer une classe d’extension
Créer les méthodes correspondant aux filtres et fonctions
Déclarer l’extension au noyau de Symfony
Utiliser l’extension
Conclusion

18/03/2016
225
Les macros
Une macro est juste une fonction définie à l’intérieur du template.
On la déclare avec la directive :
On peut importer des fichiers de macro avec la directive :

18/03/2016
226
La filtres et les fonctions
Un filtre est communément un moyen de transformer la présentation
d’une donnée.
Un filtre peut naturellement admettre des paramètres supplémentaires :
La seule différence entre les filtres et les fonctions tient à
l’échappement de la sortie

18/03/2016
227
La filtres et les fonctions
Une fonction est communément un moyen de calculer une valeur en
fonctions de certaines données.

18/03/2016
228
La classe Twig_Extension
Filtres et fonctions sont définis dans une classe d’extension qui doit
hériter de la classe Twig_Extension, qui fait partie des composants de
Symfony.
Celle-ci oblige à définir (au moins) trois méthodes :
• getFilter -> déclare la liste des filtres
• getFunctions -> déclare la liste des fonctions
• getName -> crée un nom (unique) pour la classe
d’extension

18/03/2016
229
Créer la classe d’extension
Pour créer la classe d’extension, il faut en premier lieu la placer dans le
dossier Twig d’un bundle. Et juste déclarer :
A noter que Twig_Extension est dans l’espace de noms racine

18/03/2016
230
Créer les filtres et les fonctions
Par convention, les méthodes des filtres et des fonctions sont (comme
souvent dans Symfony) suffixées.
Ainsi : crée le filtre price.
Et : crée la fonction total.

18/03/2016
232
Utiliser l’extension
Une fois cela fait, les méthodes de la classe d’extension sont utilisables
exactement comme celles fournies par défaut par Twig :

18/03/2016
233
Ce qu’on a vu
Les extensions à la syntaxe de Twig : macros, filtres et fonctions
Comment exploiter la classe Twig_Extension
Exploiter les nouveaux éléments syntaxiques pour créer des templates
plus lisibles, modulaires et réutilisables

18/03/2016
234
Michel CADENNES
Les formulaires
Introduction
aux formulaires

18/03/2016
235
Plan
Rôle des formulaires
Une méthode simple par la ligne de commande
Limites de cette méthode
La classe AbstractType
Anatomie d’une classe de formulaires
Créer un formulaire simple ex nihilo

18/03/2016
236
Le rôle des formulaires
Au niveau de HTML, un formulaire est une collection de widgets qui
sont soumis (submit) à une cible (action de l’élément form). Ces widgets
ont depuis HTML5 pris beaucoup de variété
Au niveau de PHP, un formulaire est transmis par une requête ayant un
type MIME multipart/form-data, dont les données sont stockées dans la
variable superglobale $_POST
Au niveau de Symfony, un formulaire est une interface qui doit être
mise en correspondance avec un modèle (dans la plupart des cas)

18/03/2016
237
Une méthode simple par la ligne de commande
• Symfony possède une commande qui permet de créer simplement et
de manière interactive un formulaire
php app/console generate:doctrine:form <Bundle>:<Entity>

18/03/2016
238
Limites
Cette commande crée juste un squelette minimal de classe
On ne peut pas prendre en compte les relations entre les entités du
modèle

18/03/2016
239
La classe AbstractType fournit quelques méthodes simples pour
construire des classes de formulaires. Principalement :
buildForm($form, $options) : méthode chargée de construire le
formulaire
configureOptions($resolver) : méthode permettant de paramétrer le
formulaire

18/03/2016
240
La classe AbstractType fournit aussi deux méthodes pour construire le
rendu du formulaire :

18/03/2016
241
Création d’une classe de formulaire simple
• La méthode la plus simple pour créer un formulaire consiste bien
souvent à utiliser la ligne de commande pour créer le squelette de base.
Puis à compléter la structure engendrée avec les informations
manquantes.
• D’autant que nous verrons que, dans les applications réelles, les
formulaires sont souvent plus complexes

18/03/2016
242
add
Définir un formulaire consiste la plupart du temps à ajouter des champs
au constructeur.

18/03/2016
243
Options
FormBuilderInterface définit de nombreuses méthodes pour les
constructeurs de formulaires. Parmi elles :
$options fait référence ici à l’argument de la méthode buildForm

18/03/2016
244
data_class
Bien que pas toujours requis, il est de bonne pratique d’indiquer au
formulaire quelle est l’entité associée. Ceci se fait dans
configureOptions :

18/03/2016
252
Les fonctions de formulaires pour Twig

18/03/2016
253
Personnaliser l’aspect des champs
• Il est également possible de créer ses propres gabarits d’affichage pour
des types de champs existants.
• Pour cela, il suffit de :
A. Créer un gabarit dans le dossier views d’un bundle
B. Déclarer le gabarit à Twig
C. Importer le nouveau gabarit dans le squelette de la page

18/03/2016
254
Utilisation des formulaires

18/03/2016
255
Le cycle du formulaire
Intégrer un formulaire dans un contrôleur se fait en deux temps :

18/03/2016
256
Le traitement par Doctrine
• Quand le contrôleur reçoit le formulaire rempli, il faut le faire persister.
Pour cela :
• handleRequest() : hydrate un objet avec les données du
formulaire
• persist() : déclare à Doctrine qu’un objet doit être pris en compte
• flush() : modifie le modèle

18/03/2016
257
Récupérer les erreurs
Dans le navigateur par la configuration des options
Par des classes de validation associées au formulaire
Par la détection de Symfony si rien n’est spécifié

18/03/2016
258
Ce qu’on a vu
Les champs de formulaire
Afficher et Personnaliser l’aspect des champs
Le cycle de traitement des formulaires par Symfony
La gestion des erreurs

18/03/2016
259
Michel CADENNES
Les formulaires
Formulaires complexes

18/03/2016
260
Plan
Des formulaires plus complexes
Créer un type de champ de formulaire
Associer des modèles ad hoc à un formulaire
Héritage de formulaire
Validation des données du formulaire

18/03/2016
261
Formulaires complexes

18/03/2016
262
Les formulaires enfants
• Dans bon nombre cas, les formulaires que l’on a affiché font référence à
plusieurs entités, car ces entités sont liées.
• Symfony accepte que vous embarquiez un formulaire complet à
l’intérieur d’un autre formulaire.
• Et pour afficher les champs correspondants :

18/03/2016
263
Les collections de formulaires
Si une entité est liée à plusieurs autres entités d’une même classe (e.g.
une personne qui a plusieurs adresses), il est possible d’utiliser un type
de champ CollectionType pour laisser Symfony gérer les associations
automatiquement.
Il suffit ensuite d’une boucle dans le squelette Twig pour afficher les
sous-formulaires associés.

18/03/2016
264
Les collections de formulaires
Lors du traitement du formulaire, il faudra, selon les cas, faire attention
au sens directeur de l’association si l’on veut que la persistance soit
prise en charge de manière transparente.
Symfony met à disposition une option allow_add qui autorise,
moyennant une fragment de code JavaScript, à ajouter des sous-
formulaires à la volée à la collection existante.
Symfony met également une option allow_delete pour l’effet inverse.

18/03/2016
265
Types de champs personnalisés
• Définir un type de champ personnalisé n’est pas très différent de
définir un formulaire. Il faut :
Créer une classe de formulaire et indiquer que cette classe est une
sous-classe de FormType
Créer le gabarit d’affichage associé au champ
Déclarer le gabarit au noyau de Symfony

18/03/2016
266
Les modèles de formulaire

18/03/2016
267
Les modeles de formulaire
• Un autre cas de figure est celui où l’on a besoin de champs
supplémentaires qui ne sont pas dans le modèle.
• Il est alors possible de créer une entité qui sera hébergée dans un
dossier Model du dossier Form, et de s’en servir dans l’application.

18/03/2016
268
L’héritage de formulaire

18/03/2016
269
Héritage de formulaire
• Comme les formulaires sont des classes, un bénéfice collatéral est de
pouvoir faire fonctionner le mécanisme d’héritage, ce qui s’avère
particulièrement utile si vous avez des entités organisées
hiérarchiquement :

18/03/2016
270
La validation de formulaire

18/03/2016
271
Validation de formulaire
• Pour valider des données de formulaire, la solution la plus simple est de
passer par les annotations.
• Pour cela, il faut commencer de mettre à jour le fichier config.yml :

18/03/2016
273
Validation de formulaire
• Il y a des classes de validation pour un grands nombre de propriétés
des variables : chaînes de caractères, dates, expressions régulières,
collections, fichiers.
• Les mutateurs (getters) associés à des propriétés protégées ou privées
peuvent également être validées
• En dehors des annotations, les fichiers de validation doivent être
hébergés dans le répertoire :
Resources/config/validation

18/03/2016
274
Groupes de validation
• Selon les cas, on peut souhaiter restreindre la validation à certains
champs seulement du formulaire. Dans ce cas on peut définir des
groupes de validation.
• Il suffit ensuite de déclarer le groupe considéré dans les options du
formulaire.

18/03/2016
275
Ce qu’on a vu
Créer des formulaires plus complexes
Créer ses propres types de champs
Créer des modèles de formulaire ad hoc
Hiérarchiser les classes de formulaire
Valider les données des formulaires

18/03/2016
276
Michel CADENNES
Les modèles
Introduction

18/03/2016
277
Plan
Qu’est-ce qu’un modèle ?
Construire un modèle conceptuel
Dualité des modèles : objets et relations
Introduction aux ORM

18/03/2016
278
Le modèle conceptuel
Créer un modèle conceptuel est le travail qui consiste à recenser et
organiser toutes les informations relatives à un domaine donné pour en
construire une représentation structurée.
Ces informations sont regroupées de manière à respecter la
sémantique du domaine au sein d’entités
Les entités sont organisées entre elles selon des relations signifiantes
Le modèle conceptuel est à priori indépendant de toute réalisation
technique

18/03/2016
279
Construire un modèle conceptuel
Des langages de représentation permettent de traduire les informations
relatives à un domaine en un modèle opérationnel Entité - Relation.
Une méthode comme Merise possède son propre langage
UML est un formalisme qui développé parallèlement aux méthodes
itératives
RDF, RDFS, OWL sont des langages utilisés dans le domaine du
Knowledge Engineering

18/03/2016
280
Symfony et les modèles
Symfony est conçu de manière à alléger les tâches de gestion
administrative des données
Une vision architecturale de l’application est privilégiée
Plus le travail est préparé en amont de l’implémentation, plus la partie
technique sera facilitée et automatisable.

18/03/2016
281
UML

18/03/2016
282
UML
UML est un langage de représentation qui définit des « vues »
alternatives et complémentaires sur l’application et a pour vocation
d’accompagner le développement depuis la conception jusqu’au
déploiement.
Nous nous intéresserons ici aux diagrammes de classes

18/03/2016
283
Schéma UML
Les diagrammes de classes de UML peuvent représenter
(principalement) :
Des classes (propriétés et méthodes)
Des associations (avec leur arité)
Des agrégations de classes
Des hiérarchies de classes
Des packages (regroupement logiques)

18/03/2016
284

18/03/2016
285
Export du modèle
UML a la possibilité de produire des squelettes de classes dans
différents langages dont PHP
Il est donc possible de se servir d’un outil de modélisation comme
fournisseur de matière première pour la construction d’une application
sous Symfony

18/03/2016
286
Les modèles et ORM

18/03/2016
287
Objets et relations
Le paradigme des la POO s’est généralisé à l’immense majorité des
langages de programmation
Le modèle objet ne s’est toutefois pas posé dans le monde des bases
de données
Restent trois alternatives :
Utiliser des outils comme PDO pour dialoguer avec des bases de
données relationnelles
Utiliser une couche d’abstraction permettant l’interrogation
transparente de bases de données relationnelles
Utiliser des bases NoSQL ou graphes (MongoDB, etc.)

18/03/2016
288
ORM : Object Relational Mapper
Symfony ne tranche pas définitivement entre ces alternatives.
Par défaut, il est prévu pour fonctionner avec un ORM (couche
d’abstraction) Objet/Relationnel : Doctrine
Il est possible d’utiliser d’autres ORM, comme Propel, par exemple.

18/03/2016
289
Rôle de l’ORM
Comme couche d’abstraction, l’ORM est capable de :
Transformer un objet complexe en un jeu de données adéquat pour
un ensemble de relations (au sens SQL).
Utiliser des données issues de tables de la base de données pour
« hydrater » des objets qui leur correspondent
Son rôle est aussi d’assurer la persistance des données, c’est-à-dire de
veiller à la cohérence entre l’état du programme et celui du modèle.

18/03/2016
290
Coûts des ORM
Un ORM apporte énormément de confort pour le développement
d’applications.
En revanche, cela a un coût en matière de lourdeur des applications
Il est généralement conseillé d’installer des gestionnaires de cache
comme memcache et/ou APC

18/03/2016
291
Ce qu’on a vu
Pourquoi un bon modèle est essentiel
Comment préparer un modèle conceptuel en amont d’une application
sous Symfony
Le rôle des ORM

18/03/2016
292
Michel CADENNES
Les modèles
Construction
du modèle

18/03/2016
293
Plan
Passer du modèle conceptuel au modèle de données
Les outils de Symfony
Organisation des classes de modèles dans Symfony
Les entités
Les « repositories »
Travailler avec les modèles dans l’application
« Persister » les données
Le mode transactionnel

18/03/2016
294
Introduction
• Passer du modèle conceptuel à un modèle concret utilisable dans
Symfony suppose plusieurs opérations :
1. La création d’un modèle déclaratif de l’ensemble des classes
2. La création de classes d’entités au sens PHP5
3. La création du schéma de base de données correspondant

18/03/2016
295
Les stratégies
• Il y a encore trois possibilités pour arriver à ce résultat :
1. Partir de la base de données pour créer les entités
> practicable en cas de reprise d’un site existant
2. Partir des classes d’entités pour engendre la base de données
> possible à condition de travailler avec des annotations
> permet de repartir de squelettes engendrés par des outils UML
3. Ecrire le schéma déclaratif puis engendrer les entités et la base de données
> le schéma habituel
> avec la possibilité d’utiliser la console de Symfony

18/03/2016
296
Les entités

18/03/2016
297
Architecture des entités
Toutes les entités de l’application correspondent à une classe hébergée
dans le dossier :
Les classes d’entités sont généralement accompagnées d’une classe de
requête (repository) qui porte le nom de l’entité suffixée par Repository :
Entity

18/03/2016
298
Architecture des entités
Par ailleurs, toutes les entités doivent être déclarées à Doctrine. Elles
peuvent l’être sous deux formes :
Par des annotations incluses dans le fichier de la classe d’entité
Par un fichier de déclaration hébergé dans le dossier :

18/03/2016
299
Un déclaration simple

18/03/2016
300
La classe de requêtes
• A toute entité peut être associée une classe de requêtes permettant
d’explorer le modèle.
• Ces classes héritent toutes, directement ou indirectement, de la classe :
• La syntaxe des requêtes fera l’onjet d’une session particulière.

18/03/2016
304
Entity Manager
• L’Entity Manager a pour rôle :
de gérer les requêtes au modèle (via les classes de requêtes)
de gérer la persistance des données, c’est-à-dire assurer la
sauvegarde et la restauration des données, ainsi que la
synchronisation entre l’état du programme et le modèle.

18/03/2016
305
Entity Manager : requêtes
• L’Entity Manager permet l’accès à la classe de requêtes de l’entité :
• C’est ensuite le Repository qui prend en charge les requêtes :

18/03/2016
306
La persistance

18/03/2016
307
Le mécanisme de la persistance
Base de données
Unité de travail
flush, commit, rollback
transactional
contrôleur
persist, merge,
remove, detach

18/03/2016
308
L’Unité de Travail (UnitOfWork) est chargée de maintenir à jour toutes
les tâches à réaliser pour maintenir la synchronisation entre état du
programme et la base de données
Chaque entité devant être ajoutée au modèle ou modifiée doit être
déclarée à l’Unité de Travail (persist)
Les entités extraites du modèle sont automatiquement déclarées à
l’Unité deTravail
Les entités sont manipulées dans l’Unité de Travail jusqu’au moment où
le modèle est remis à jour (flush)

18/03/2016
309
Persister

18/03/2016
310
persist
• La méthode persist n’a a être appelée explicitement que lors de la
création d’un objet.
• Elle ajoute cet objet à la liste des entités à ajouter au modèle.

18/03/2016
311
remove
La méthode remove indique à l’Unité de Travail que l’entité considérée
devra être ôtée du modèle lors de la prochaine synchronisation.

18/03/2016
312
detach
La méthode detach permet de retirer une entité de la liste des entités à
synchroniser par l’Unité de Travail

18/03/2016
313
merge
• La méthode merge permet de réassigner à l’Unité de Travail une entité
à prendre en charge (par exemple, parce qu’elle a été détachée ou
sérialisée)
• Pour une nouvelle entité, merge est équivalent de persist.

18/03/2016
314
clear
• La méthode clear vide l’Unité de Travail.

18/03/2016
315
La synchronisation

18/03/2016
316
flush
• La méthode la plus couramment utilisée est flush.
• Elle inspecte toutes les entités contenues dans l’Unité de Travail et met
à jour la base de données.
• flush travaille implicitement dans un mode « auto-commit »

18/03/2016
318
Ce qu’on a vu
Comment passer d’un modele conceptuel à un schéma de base de
données
Comment créer des entités représentant le modèle de données de
l’application
Quelle est l’architecture des entités dans Symfony
Le rôle du moteur de persistance
Le fonctionnement du moteur par défaut de Symfony : Doctrine

18/03/2016
319
Michel CADENNES
Les modèles
La persistance

18/03/2016
320
Plan
Les mécanismes de persistance
La gestion de l’Unité de Travail
La synchronisation du modèle
Le mode transactionnel

18/03/2016
321
La persistance

18/03/2016
322
Base de données
Unité de travail
flush, commit, rollback
transactional
contrôleur
persist, merge,
remove, detach

18/03/2016
323
L’Unité de Travail (UnitOfWork) est chargée de maintenir à jour toutes
les tâches à réaliser pour maintenir la synchronisation entre état du
programme et la base de données
Chaque entité devant être ajoutée au modèle ou modifiée doit être
déclarée à l’Unité de Travail (persist)
Les entités extraites du modèle sont automatiquement déclarées à
l’Unité deTravail
Les entités sont manipulées dans l’Unité de Travail jusqu’au moment où
le modèle est remis à jour (flush)

18/03/2016
324
Persister

18/03/2016
325
persist
• La méthode persist n’a a être appelée explicitement que lors de la
création d’un objet.
• Elle ajoute cet objet à la liste des entités à ajouter au modèle.

18/03/2016
326
remove
La méthode remove indique à l’Unité de Travail que l’entité considérée
devra être ôtée du modèle lors de la prochaine synchronisation.

18/03/2016
327
detach
La méthode detach permet de retirer une entité de la liste des entités à
synchroniser par l’Unité de Travail

18/03/2016
328
merge
• La méthode merge permet de réassigner à l’Unité de Travail une entité
à prendre en charge (par exemple, parce qu’elle a été détachée ou
sérialisée)
• Pour une nouvelle entité, merge est équivalent de persist.

18/03/2016
329
clear
• La méthode clear vide l’Unité de Travail.

18/03/2016
330
La synchronisation

18/03/2016
331
flush
• La méthode la plus couramment utilisée est flush.
• Elle inspecte toutes les entités contenues dans l’Unité de Travail et met
à jour la base de données.
• flush travaille implicitement dans un mode « auto-commit »

18/03/2016
332
commit / rollback / transactional
• Il est possible de gérer manuellement la mise à jour du modèle en
utilisant commit pour procéder à la mise à jour et rollback pour la
restauration en cas d’erreur.
• Doctrine fournit une méthode transactionalle qui encapsule la gestion
de la restauration :

18/03/2016
339
One to One unidirectionnel

18/03/2016
340
Exemple
id_avatar
id
id_personne
id

18/03/2016
341
One to One bidirectional

18/03/2016
342
Many to one

18/03/2016
343
Exemple
id_acheteur
id
id_acheteur
id_acheteur
id_acheteur

18/03/2016
344
Many To One unidirectionnel

18/03/2016
345
Exemple
id
id_acheteur
id_acheteur
id_acheteur
id_acheteur
achats

18/03/2016
346
Many To One bidirectionnel (+ One To Many)

18/03/2016
347
Many to many

18/03/2016
348
Exemple
id
id
id
id
id
id
id_auteur id_livre
id_auteur id_livre
id_auteur id_livre
id_auteur id_livre
id_auteur id_livre

18/03/2016
349
Many To Many bidirectionnel

18/03/2016
350
Héritage d’entités

18/03/2016
351
Héritage d’entités
Le modèle Doctrine peut refléter la hiérarchie des classes du modèle
conceptuel de l’application.
Dans ce cas, il y a deux choses à faire :
1. Déclarer la liste des entités-enfants dans l’entité-parent
2. Supprimer la clef primaire de l’entité-enfant

18/03/2016
352
Transformation de l’entité-parent

18/03/2016
353
En pratique
Dans la pratique, on suit le processus suivant :
Création du schéma des entités
Engendrement des classes d’entités
Ajout de l’héritage dans les classes d’entités produites
Création du schéma de la base de données

18/03/2016
354
En pratique
N.B. 1 : L’entité-parent joue le rôle d’une classe abstraite, bien que la
classe correspondante ne soit pas nécessairement définie comme telle
N.B. 2 : La classe parent permet de mutualiser un grand nombre de
méthodes communes - toutes les classe enfants.

18/03/2016
355
Ce qu’on a vu
Les différentes sortes d’associations entre entités
L’importance de la direction de l’association
La mise en œuvre de l’héritage entre entités dans le modèle Doctrine
Les stratégies de gestion des tables SQL

18/03/2016
356
Michel CADENNES
Les modèles
Les langages
de requêtes

18/03/2016
357
Plan
Classes de requêtes
QueryBuilder
L’objet QueryBuilder
Récupérer les résultats
Ecrire des requêtes complexes

18/03/2016
358
Les classes de requêtes

18/03/2016
359
Toutes les requêtes se trouvent dans les classes de « Repository » (ou
dépôt) associées aux entités
Ces requêtes concernent principalement l’extraction de données du
modèle. L’ajout, la modification et la suppression étant en fait gérés
directement à partir du contrôleur
Les classes de requêtes sont utiles pour les requêtes complexes.
Doctrine admet 3 syntaxes différentes pour exprimer ces requêtes

18/03/2016
360
Les classes de requêtes sont en général crées automatiquement lors de
la création des entités
Elles suivent une règle de nommage habituelle dans Symfony
Classe d’entité : Auteur.php
Classe de requête : AuteurRepository.php

18/03/2016
361
• Les contrôleurs possèdent un accès direct aux classes de requêtes via
le service Entity Manager

18/03/2016
362
L’objet querybuilder

18/03/2016
363
QueryBuilder
QueryBuilder fournit une API pour engendrer des requêtes SQL à partir
d’un langage objet.
Elle est initialisée par l’instruction :
N.B. : le paramètre ‘u’ est totalement arbitraire, la requête étant
automatiquement liée à l’entité à laquelle fait référence la classe

18/03/2016
365
L’API QueryBuilder
join
innerJoin
leftJoin
where
orWhere
andWhere
groupBy
addGroupBy
having
andHaving
orHaving
ordrerBy
addOrderBy

18/03/2016
366
Exemple
N.B. : Les requêtes ne manipulent que les propriétés des objets et jamais les
champs de la base de données

18/03/2016
367
Les paramètres
• Pour rendre l’insertion deq variables dans les requêtes, on a recours à
la méthode :

18/03/2016
368
Exemple

18/03/2016
369
Limiter les résultats
• Pour prendre juste un segment de l’ensemble des résultats :

18/03/2016
370
Exécuter la requête
Une fois la requête construite, il ne reste plus qu’à engendrer le SQL
correspondant, ce qui est fait par :
Et récupérer les résultats :

18/03/2016
371
Les résultats
N.B. : Doctrine rend une collection d’objets, instances des entités déclarées
dans la requête

18/03/2016
372
Les fonctions selectives

18/03/2016
373
La classe Expr
• Doctrine peut exprimer un sous-ensemble (restreint) des fonctions
disponibles en SQL au travers de la classe Expr.

18/03/2016
374
Conclusion

18/03/2016
375
QueryBuilder est une API de haut niveau
Elle permet de faire complètement abstraction de la couche SQL
Elle permet de construire les requêtes bloc par bloc
Elle laisse Doctrine optimiser le SQL produit
Elle ne couvre qu’un sous-ensemble de SQL
Elle est naturellement plus lente que du SQL natif

18/03/2016
376
Ce qu’on a vu
Le lien organique entre les classes d’entités et les classes de requêtes
Comment construire une requête avec l’objet QueryBuilder
Les avantages et les inconvénients de cette méthode

18/03/2016
377
Michel CADENNES
Les modèles
DQL

18/03/2016
378
Plan
Présentation de DQL
Les requêtes avec DCL
Fonctions, opérateurs, agrégats

18/03/2016
379
DQL

18/03/2016
380
Présentation
DQL est l’acronyme de Doctrine Query Language
C’est un langage assez similaire à Hibernate dans l’univers Java, voire
SPARQL pour le web sémantique.
C’est un langage utilisant une syntaxe SQL, mais appliquée à des objets
(entités de Symfony) et non des champs/tables SQL
Doctrine produit le SQL associé et l’optimise

18/03/2016
381
Les classes de requêtes sont en général crées automatiquement lors de
la création des entités
Elles suivent une règle de nommage habituelle dans Symfony
Classe d’entité : Auteur.php
Classe de requête : AuteurRepository.php

18/03/2016
382
• Les contrôleurs possèdent un accès direct aux classes de requêtes via
le service Entity Manager

18/03/2016
383
Les requêtes avec DQL

18/03/2016
384
Créer une requête
DQL fournit une manière de créer des requêtes beaucoup plus proche
de ce que l’on connaît avec PDO.
N.B. : La syntaxe SQL-like peut être trompeuse. On a bien à faire ici à des
fonctions DQL

18/03/2016
385
Les paramètres
• DQL supporte également les paramètres positionnés et nommés

18/03/2016
388
Les Fonctions DANS DQL
Fonctions, opérateurs, agrégats

18/03/2016
389
Les fonctions
• Comme QueryBuilder, DQL sait exprimer un sous-ensemble des
fonctions SQL.
• La liste des fonctionnalités admises est en ligne dans la
documentation de Doctrine
Syntaxe abstraite de DQL

18/03/2016
390
Exemples
'SELECT u, COUNT(g.id) FROM User u JOIN u.groups g GROUP BY u.id');
'SELECT u.name FROM User u WHERE u.id IN(46, 53, 95, 144)’);
'SELECT u.id FROM CmsUser u WHERE EXISTS (
SELECT p.phonenumber FROM CmsPhonenumber p WHERE p.user = u.id)’
);

18/03/2016
391
PARTIAL
• Utiliser la fonction PARTIAL permet de récupérer des objets et non un
tableau (hiérarchique) de valeurs

18/03/2016
392
INDEX BY
• La fonction INDEX BY permet de choisir les valeurs des clefs du
tableau associatif des résultats.

18/03/2016
393
Conclusion

18/03/2016
394
A retenir
DQL a une syntaxe proche de SQL
DQL est la syntaxe sous-jacente à QueryBuilder
Moins modulaire que QueryBuilder

18/03/2016
395
Ce qu’on a vu
La syntaxe de Doctrine Query Language
Les différences avec QueryBuilder

18/03/2016
396
Michel CADENNES
Les modèles
Native SQL

18/03/2016
397
Plan
Présentation de Native SQL
Le ResultSetMappingBuilder
Les requêtes natives

18/03/2016
398
Native SQL

18/03/2016
399
Présentation
Dans certains cas, on a besoin de concevoir des requêtes qui utilisent
pleinement la syntaxe SQL
On utilise alors Doctrine pour apparier les résultats sur les propriétés de
certains objets/entités
Il est nécessaire de déterminer cet appariement

18/03/2016
400
Le resultSET
Déterminer l’appariement champs/propriétés

18/03/2016
401
Le Result set
des entités : les éléments racines des résultats
des entités jointes : liées par des associations aux entités « racine »
des champs : appartenant aux entités ci-dessus
des valeurs scalaires :
des méta-données : comme des clefs étrangères ou des colonnes de
discrimination

18/03/2016
402
Ajouter une entité

18/03/2016
403
Ajouter une entité jointe

18/03/2016
404
Ajouter un champ

18/03/2016
405
Ajouter une entité

18/03/2016
407
Ajouter une entité

18/03/2016
408
Une requête native

18/03/2016
409
Une requête native
Créer une requête native se fait par la méthode createNativeQuery
Le corps de la requête est du SQL standard

18/03/2016
410
Les résultats
N.B. 1 : En fonction de la requête, Doctrine rend des objets qui
peuvent être partiels
N.B. 2 : Le ResultSetMapping est persistent. Il faut donc l’annuler
avec la fonction clear() une fois la requête achevée

18/03/2016
411
Les requêtes nommées

18/03/2016
412
Déclarer une requête nommée
• Un avantage de Native SQL est de pouvoir être déclarée dans le modèle
de l’entité.
• On ajoute alors un élément <sql-result-set-mappings> pour déclarer
les Result sets
• On ajoute également un élément <named-native-queries> pour les
requêtes elles-mêmes

18/03/2016
413
Exemple

18/03/2016
414
Utilisation
Une fois enregistrée, la requête nommée peut être utilisée directement
dans le contrôleur

18/03/2016
415
Conclusion

18/03/2016
416
A retenir
Native SQL permet de créer des requêtes conformes à SQL,
arbitrairement complexes
La mise en œuvre est plus lourde que les autres méthodes
Risque d’engendrer des effets de bords

18/03/2016
417
Ce qu’on a vu
Comment utiliser des requêtes SQL avec les entités Doctrine
Comment paramétrer un Result set
Quand utiliser cette syntaxe

18/03/2016
418
Michel CADENNES
Les services
Introduction

18/03/2016
419
Plan
Architecture de services
Définition des services
Créer un service
Déclarer un service à Symfony
Utiliser un service
Un service simple

18/03/2016
420
Qu’est-ce qu’un service ?
• Un service est un composant logiciel autonome réalisant une
fonctionnalité clairement définie.
• Un service encapsule une collection d’opérations qui constituent autant
d’actions spécifiques que le service peut effectuer.
• Un service coopère avec d’autres services disponibles pour répondre à
une requête.

18/03/2016
421
Caractéristiques d’un service
Un contrat qui indique comment il peut être utilisé
Un ensemble de dépendances faibles à d’autres services
Une abstraction d’une partie de logique métier
Une faculté à être réutilisable
Une garantie d’autonomie (avec délégation éventuelle)
Une possibilité d’être découvert (via un annuaire)
Un élément essentiellement composable
Une recherche de la granularité optimale

18/03/2016
422
Architecture orientée services
Montée en puissance de modèles SOA depuis quelques années
Application au web avec les « webservices »
Le web est une plate-forme très bien adaptée à ce type d’architecture
Développement d’outils :
Annuaire (UDDI) pour la découverte de services
WSDL, XML pour la description des contrats
SOAP pour l’invocation des services
Utilisation de HTTP pour le transport

18/03/2016
423
Les services dans Symfony
Les services ne sont pas des « services web »
Leur fonction n’est pas d’exposer un service sur le réseau
Ils ont un rôle central dans Symfony comme outil de modularisation &
composition du code
Beaucoup d’objets d’une application peuvent être définis comme
services et référencés comme tels dans l’annuaire nommé « conteneur
de services »
Les services sont des singletons (instanciés une seule fois)
Les services sont hébergés par les bundles

18/03/2016
424
Qu’est-ce qu’un service ?
1. une « vanilla PHP class ».
2. une déclaration de service
• Un service est :

18/03/2016
425
Déclarer un service
• Déclarer un service est très simple, puisqu’il suffit d’exposer un fichier
services.*ml dans le dossier :
Resources/config
• Il suffit juste de leur donner une étiquette et d’indiquer à Symfony la
classe PHP correspondante :
<service id="tdn.image_processor" class="%image.processor.class%">

18/03/2016
426
Services et contrôleurs
• Les objets héritant de la classe Controller (ou implémentant
ContainerAware) ont un acces direct au contenu de services.
• Pour cette raison, invoquer un service à l’intérieur d’un contrôleur se
fait par la méthode ‘get'.
$processor = $this->get(‘tdn.image_processor’);

18/03/2016
427
Un service simple
Dans ce qui suit, nous allons développer un service simple
qui ira chercher chercher des données sur des sites
externes.

18/03/2016
428
Ce qu’on a vu
Ce qu’était un service
Comment sont utilisés les services dans Symfony
Implémenter des services simples

18/03/2016
429
Michel CADENNES
Les services
L’injection
de dépendances

18/03/2016
430
Plan
L’injection de dépendances (design pattern)
Un service simple avec dépendances

18/03/2016
431
Présentation
• L’injection de dépendances est un cadre de conception (design pattern)
qui :
« consiste à créer dynamiquement (injecter) les dépendances
entre les différentes classes en s'appuyant sur une description
(fichier de configuration ou métadonnées) ou de manière
programmatique.
Ainsi les dépendances entre composants logiciels ne sont
plus exprimées dans le code de manière statique mais
déterminées dynamiquement à l’exécution. »
Wikipedia

18/03/2016
432
Trois types d’injections
Injection par constructeur : les dépendances sont évaluées et créées
lors de l’instanciation de l’objet de la classe de service,
Injection par méthode : le service définit un mutateur (setter) qui est
chargé de prendre en charge la dépendance,
Injection par interface : on définit une interface qui permettra à tout
service qui l’implémente de nouer une dépendance.

18/03/2016
433
Les Arguments

18/03/2016
434
Ajouter une dépendance : les arguments
• Dans Symfony, si l’on veut qu’un service dépends d’autres services, il
faut l’indiquer dans la déclaration en ajoutant des arguments. Ceux-ci
peuvent être de trois types :
d’autres services
des paramètres définis ailleurs dans l’application
des constantes
une expression

18/03/2016
435
Impact sur la classe de service
• Les arguments doivent être insérés dans la signature du constructeur
=> il s’agit d’une injection par constructeur
<argument type=‘service’>AppBundleService</argument>

18/03/2016
436
Les « calls »
L’injection par mutateur

18/03/2016
437
Dépendances de méthode : les calls
• Les calls sont un moyen d’ajouter de nouvelles dépendances, sans
avoir à modifier le constructeur. Elles peuvent donc également devenir
optionnelles. Les calls eux-mêmes font référence à un argument :
• Ici, il faudra de plus définir une méthode semailles dans la classe de
service

18/03/2016
441
Exemples
form.type : permet d’enregistrer de nouveaux types de champs formulaire
console.command : ajouter une commande à la console de Symfony
kernel.event_listener : ajouter une action à un hop du noyau
monolog.logger : ajouter un canal de log à Monolog
routing.loader : ajouter un méthode personnalisée de chargement des routes
templating.helper : définir un service accessible dans les template PHP
validation.constraint_validator : définir ses propres contraintes de validation

18/03/2016
442
Un service avec dépendances

18/03/2016
443
Implémentation
• Dans la démonstration qui suit, nous allons implémenter un service qui
s’appuiera sur celui de la première partie (par injection) et proposera des
méthodes pour post-traiter les informations reçues.

18/03/2016
444
Ce qu’on a vu
Le principe de l’injection de dépendances
Les techniques dans Symfony
Déclarer un argument pour un service
Déclarer un call
Comment associer un service à des composants du noyau de Symfony
L’implémentation d’in service avec dépendances

18/03/2016
445
Michel CADENNES
Les services
Tout est service

18/03/2016
446
Plan
Intégrer les services du noyau dans ses propres services
Les principaux services de Symfony
Accéder au routeur
Les contrôleurs comme services
Les formulaires comme services
Personnaliser les fichiers de déclaration de services

18/03/2016
447
Les principaux services
doctrine.orm.entity_manager
event_dispatcher
kernel
logger
mailer
request_stack
router
security.context
service_container
twig
templating

18/03/2016
448
Exemple : accéder au routeur

18/03/2016
449
Accéder à l’environnement
• Les environnements sont principalement définis par leurs fichiers de
configuration. C’est à priori la même base de code qui s’exécute.
• Néanmoins, on peut vouloir savoir à un moment du cycle dans quel
environnement l’on se trouve.

18/03/2016
450
Déclarer un contrôleur comme service
• Un contrôleur peut être un service, il suffit de le déclarer comme tel :
• Il est ensuite possible de l’appeler :

18/03/2016
451
Déclarer un contrôleur comme service
• Déclarer un contrôleur comme service rend aussi superflu la nécessité
d’hériter de la classe Controller.
• Vous pouvez alors paramétrer exactement les services dont votre
contrôleur aura besoin.

18/03/2016
452
Déclarer un formulaire comme service
• De la même manière, il est possible de déclarer une classe de
formulaire :

18/03/2016
453
Déclarer un formulaire comme service
• On peut ensuite directement utiliser l’alias dans le contrôleur :

18/03/2016
454
Personnaliser les fichiers de déclaration
• Lorsque l’on crée un bundle, Symfony engendre automatiquement un
dossier :
DependancyInjection
• Et à l’intérieur un fichier :
DependancyInjection/<nomDuBundle>Extension.php

18/03/2016
455
Personnaliser les fichiers de déclaration
• La classe d’extension définit une méthode load qui permet de
personnaliser l’emplacement des fichiers de déclaration de services
• En changeant le où du fichier (voire le répertoire) ou en ajoutant des
lignes, il est possible de rendre plus modulaire la déclaration des
services de l’application
$loader->load(‘services.xml’);

18/03/2016
456
Ce qu’on a vu
Accéder à des services en dehors des contrôleurs
Accéder aux configurations d’environnement
Généraliser la notion de service
Paramétrer la déclaration des services

18/03/2016
457
Michel CADENNES
Conclusion
Le mot de la fin

18/03/2016
458
Plan
Rappel des objectifs du cours
Une synthèse des points abordés dans les différents chapitres
Ce qui n’a pas été couvert, mais le sera par la suite

18/03/2016
459
Objectifs
Le but de ce cours était d’expliquer les fondements de l’architecture
d’une application dans l’environnement Symfony
Découvrir les composants principaux proposés par Symfony
Comprendre le cycle d’exécution d’une requête
Créer et organiser son code pour construire une application simple
Repérer les bonnes pratiques de Symfony et de PHP en général
Intégrer les fonctionnalités avancées de PHP 5.3+ et les contraintes
de Symfony

18/03/2016
460
Une petite synthèse

18/03/2016
461
PHP
Depuis PHP 5.3 de nombreuses fonctionnalités ont été ajoutées :
espaces de noms (5.3)
import de fonctions et de constantes séparées (5.6)
fonctions anonymes (5.3)
traits (5.4)
résolution statique à la volée (5.3)
opérateur de décomposition (5.6)
PHP offre de nouvelles possibilités d’adopter un style de
programmation fonctionnelle :
générateurs (5.5)
découverte de type généralisée (7.0)

18/03/2016
462
Composer
Le gestionnaire de paquets pour PHP
Automatise la mise à jour et la migration d’applications
Repose sur le dépôt Packagist.com

18/03/2016
463
Installation & configuration
Symfony propose plusieurs méthodes pour le « bootstrap » des
applications
Les langages et formats pour la configuration des applications sont très
variés
D’une manière générale, Symfony laisse une grande marge de
manœuvre aux développeurs
Il est fortement conseillé, néanmoins, de suivre les principales
recommandations PSR-x

18/03/2016
464
Les bundles
Un bundle (ou « bouquet » en français) est une unité fonctionnelle qui
agence les ressources (MVC, notamment) que Symfony attend
Les bundles doivent être pensés comme étant réutilisables dans
d’autres contextes (et potentiellement distribuables)
Les bundles peuvent se constituer en hiérarchie et hériter les uns des
autres

18/03/2016
465
Routage
Les routes se définissent par l’intermédiaire de fichiers de configuration
Ces fichiers sont associés aux bundles, mais peuvent être distribués ou
globalisés
Le routeur discrimine les routes en fonction de contraintes déclarées
Le routeur peut être appelé en tant que service

18/03/2016
466
Les contrôleurs
Le contrôleur est la « tour de contrôle » du cycle d’exécution
Il a un accès direct au conteneur de services via l’interface
ContainerAwareInterface
Son rôle doit se limiter à :
La réception de la requête HTTP
L’appel à des services pour le traitement des données
… en particulier la délégation de la gestion de la persistance du modèle
L’envoi de la réponse HTTP

18/03/2016
467
Les vues
Les vues peuvent être gérées de deux manières :
en PHP natif
en recourant au moteur de template Twig
Twig offre la possibilité de :
rendre les squelettes des vues modulaires
disposer d’une abstraction, davantage portable
concevoir facilement des extensions de la syntaxe de base
D’autres syntaxes (Smarty, Markdown) peuvent être facilement
intégrées à Symfony

18/03/2016
468
Les formulaires
Les formulaires sont définies de manière déclarative dans des classes
spécifiques
Le rendu des formulaires de fait fait par la configuration de champs de
formulaires, eux-mêmes extensibles
Le traitement des formulaires est pris en charge par Doctrine via les
contrôleurs
Symfony offre un système évolué de validation pour les données des
formulaires

18/03/2016
469
Les modèles
Par défaut, Symfony utilise l’ORM Doctrine comme outil de persistance
des modèles
Doctrine prend en charge la chaîne de réification du modèle conceptuel
des donnes
En tant qu’ORM, Doctrine offre une abstraction objet du schéma SQL
associé à l’application
Doctrine autorise la construction de requêtes dans plusieurs langages
de plus ou moins « haut niveau »

18/03/2016
470
Les services
La notion de service est la pierre angulaire de la modularisation du
code dans Symfony
Un service n’est en soi qu’une classe vanilla-PHP
Toute classe peut de venir un service dans Symfony
Les services n’ont d’utilité que par la combinaison de :
L’agrégation des services au sein du conteneur de services
L’assemblage des services par mâle biais de l’injection de dépendances
Des services peuvent être collectés pour étendre les fonctionnalités
d’autres services

18/03/2016
471
Encore à venir

18/03/2016
472
Cusrus Symfony
Les
Fondamentaux
Les composants
de Symfony
Avancé
Silex
Design patterns
Le projet
Sonata

18/03/2016
473
Ce qui reste à voir
La gestion des utilisateurs
La sécurité
Les événements
Le fonctionnement de la console
Les applications multilingues
Les différents caches
La configuration de services
Les politiques de tests (PHPUnit)
La création de services web
Les SGBD non SQL
etc.

Alphorm.com Support de la Formation Symfony 3 , les fondamentaux-ss

Contenu connexe

Tendances (20)

En vedette (20)

Similaire à Alphorm.com Support de la Formation Symfony 3 , les fondamentaux-ss (20)

Plus de Alphorm (20)

Dernier (10)

Alphorm.com Support de la Formation Symfony 3 , les fondamentaux-ss