Programmation PHP avec Symfony/Version imprimable

Programmation PHP avec Symfony

Une version à jour et éditable de ce livre est disponible sur Wikilivres,
une bibliothèque de livres pédagogiques, à l'URL :
https://fr.wikibooks.org/wiki/Programmation_PHP_avec_Symfony

Vous avez la permission de copier, distribuer et/ou modifier ce document selon les termes de la Licence de documentation libre GNU, version 1.2 ou plus récente publiée par la Free Software Foundation ; sans sections inaltérables, sans texte de première page de couverture et sans Texte de dernière page de couverture. Une copie de cette licence est incluse dans l'annexe nommée « Licence de documentation libre GNU ».

Introduction

Présentation

Symfony (parfois abrégé SF) est un cadriciel MVC libre écrit en PHP (> 5). En tant que framework, il facilite et accélère le développement de sites et d'applications Internet et Intranet. Il propose en particulier :

• Une séparation du code en trois couches, selon le modèle MVC, pour une plus grande maintenabilité et évolutivité.
• Des performances optimisées et un système de cache pour garantir des temps de réponse optimums.
• Le support de l'Ajax.
• Une gestion des URL parlantes (liens permanents), qui permet de formater l'URL d'une page indépendamment de sa position dans l'arborescence fonctionnelle.
• Un système de configuration en cascade qui utilise de façon extensive le langage YAML.
• Un générateur de back-office et un "démarreur de module" (scaffolding).
• Un support de l'I18N - Symfony est nativement multi-langue.
• Une architecture extensible, permettant la création et l'utilisation de composants, par exemple un mailer ou un gestionnaire de fichiers .css et .js (minification).
• Des bundles :
  • Un templating simple, basé sur PHP et des jeux de "helpers", ou fonctions additionnelles pour les gabarits... Comme alternative au PHP, on peut aussi utiliser le moteur de templates Twig dont la syntaxe est plus simples.
  • Une couche de mapping objet-relationnel (ORM) et une couche d'abstraction de données (cf. Doctrine et son langage DQL).

Utilisations

Plusieurs autres projets notables utilisent Symfony, parmi lesquels :

• https://github.com/drupal/drupal : le système de gestion de contenu (CMS) Drupal.
• https://github.com/joomla/joomla-cms : le CMS Joomla.
• https://github.com/sulu/sulu : le CMS Sulu.
• https://github.com/Sylius/Sylius : Sylius, un CMS d'e-commerce.
• https://github.com/x-tools/xtools : Xtools, un compteur d'éditions des wikis.

Différences entre les versions

Depuis la version 4, des pages récapitulant les nouvelles fonctionnalités sont mises à disposition :

• https://symfony.com/blog/symfony-4-1-curated-new-features
• https://symfony.com/blog/symfony-4-2-curated-new-features
• https://symfony.com/blog/symfony-4-3-curated-new-features
• https://symfony.com/blog/symfony-4-4-curated-new-features
• https://symfony.com/blog/symfony-5-0-curated-new-features
• https://symfony.com/blog/symfony-5-1-curated-new-features
• https://symfony.com/blog/symfony-5-2-curated-new-features
• https://symfony.com/blog/symfony-5-3-curated-new-features
• https://symfony.com/blog/symfony-6-1-curated-new-features
• https://symfony.com/blog/symfony-6-2-curated-new-features
• https://symfony.com/blog/symfony-6-3-curated-new-features

Créer un projet

Page d'accueil par défaut.

Vous trouverez sur la page dédiée Symfony 4 comment installer cette version sortie en 2017, et Symfony 3 ici. La v5 s'installe comme la v6, mais pour migrer de la v5 à la v6 il faut vérifier plusieurs choses.

Pour créer un nouveau projet sous Symfony 6, tapez la commande :

composer create-project "symfony/skeleton:^6" mon_projet

ou avec la commande "symfony" :

wget https://get.symfony.com/cli/installer -O - | bash
symfony new mon_projet

Cette commande a pour effet la création d'un dossier contenant les bases du site web à développer.

Lancer le projet

On entend par cette expression le lancement d'un serveur web local pour le développement de l'application et le choix d'un hébergeur pour la déployer (autrement dit "la mettre en production").

Serveur web de développement

Symfony intègre un serveur web local qu'on peut lancer avec la commande (se placer dans le répertoire du projet auparavant) :

$ symfony server:start -d

En passant open:local en argument de la commande symfony, le projet s'ouvre dans un navigateur :

$ symfony open:local

Ou bien en utilisant le serveur web intégré à php

$ php -S localhost:8000 -t public

Serveur web de production

Pour le déploiement dans le monde "réel", il faut choisir un hébergeur web sur internet supportant PHP (nous l’appellerons "serveur web distant" pour le distinguer du précédent). Voici quelques exemples :

• https://www.lws.fr/hebergement_web.php
• https://www.hostinger.fr/hebergeur-web
• et surtout... https://symfony.com/cloud/

Autrement il est aussi possible d'installer un deuxième serveur web (autre que celui intégré à Symfony) sur sa machine pour se rendre compte du résultat final. Par exemple... Apache qui est très répandu chez les hébergeurs profesionnels. Il faudra alors ajouter un vhost et un nom de domaine dédiés au site Symfony. Pour le test, le domaine peut juste figurer dans /etc/hosts.

Le nom de domaine du site doit absolument rediriger vers le dossier /public. En effet, si on cherche à utiliser le site Symfony dans le sous-répertoire "public" d'un autre site, la page d'accueil s'affichera mais le routing ne fonctionnera pas.

Configurer le projet

Paramètres dev et prod

Les différences de configuration entre le site de développement et celui de production (par exemple les mots de passe) peuvent être définies de deux façons :

• Dans le dossier config/packages. config.yml contient la configuration commune aux sites, config_dev.yml celle de développement et config_prod.yml celle de production.
• Via le composant Symfony/Dotenv (abordé au chapitre suivant).

Par exemple, on constate l'absence de la barre de débogage (web_profiler) par défaut en prod. Une bonne pratique serait d'ajouter au config_dev.yml :

web_profiler:
    toolbar: true
    intercept_redirects: false

twig:
    cache: false

# Pour voir tous les logs dans la console shell (sans paramètre -vvv)
monolog:
    handlers:
        console:
            type: console
            process_psr_3_messages: false
            channels: ['!event', '!doctrine', '!console']
            verbosity_levels:
                VERBOSITY_NORMAL: DEBUG

Les fichiers .yml contenant les variables globales sont dans app\config\.

Par exemple en SF2 et 3, le mot de passe et l'adresse de la base de données sont modifiables en éditant parameters.yml (non versionné et créé à partir du parameters.yml.dist). L'environnement de test passe par web/app_dev.php, et le mode debug y est alors activé par la ligne Debug::enable(); (testable avec %kernel.debug% = 1).

Depuis SF4, il faut utiliser un fichier .env non versionné à la racine du projet, dont les lignes sont injectées ensuite dans les .yaml avec la syntaxe : '%env(APP_SECRET)%'. Le mode debug est activé avec APP_DEBUG=1 dans ce fichier .env.

 en YAML, on préfèrera déclarer les services avec des simples quotes car les doubles nécessitent d'échapper les antislashs.

Les variables d'environnement du système d'exploitation peuvent remplacer celles des .env.

Commandes

Les commandes sont, avec les contrôleurs, les seuls points d'entrée permettant de lancer le programme.

La liste des commandes disponibles en console est visible avec :

php bin\console

Dans Symfony 2 c'était php app\console.

Parmi les principales commandes natives au framework et à ses bundles, on trouve :

• php bin/console list : liste toutes les commandes du projet.
• php bin/console debug:router : liste toutes les routes (URL) du site.
• php bin/console debug:container : liste tous les services avec leurs alias (qui sont des instanciations des classes).
• php bin/console debug:container --parameters : liste les paramètres.
• php bin/console debug:container --env-vars : liste les variables d'environnement.
• php bin/console debug:autowiring --all : liste tous les services automatiquement déclarés.
• php bin/console debug:config NomDuBundle : liste tous les paramètres disponibles pour paramétrer un bundle donné.
• php bin/console cache:clear : vide la mémoire cache du framework.
• php bin/console generate:bundle : crée un bunble (surtout pour SF2).
• php bin/console generate:controller : crée un contrôleur (en SF2).
• php bin/console doctrine:migrations:generate; chown 1001:1001 -R app/DoctrineMigrations : génère un fichier vide de migration SQL ou DQL.
• php bin/console doctrine:migrations:list : liste les noms des migrations disponibles (utiles car selon la configuration on doit les appeler par leur namespace ou juste par numéro).

Le mode le plus verbeux est obtenu en ajoutant "- vvv" après la commande.

Créer une commande

Lors du lancement d'une commande, on distingue deux types de paramètres :

1. Les arguments : non nommés
2. Les options : nommées.

Exemple :

bin/console app:ma_commande argument1 --option1=test

#[AsCommand(name: 'app:ma_commande')]
class HelloWorldCommand extends Command
{
    protected function configure(): void
    {
        $this
            ->addArgument(
                'argument1',
                InputArgument::OPTIONAL,
                'Argument de test'
            )
            ->addOption(
                'option1',
                null,
                InputOption::VALUE_OPTIONAL,
                'Option de test'
            )
        ;
    }

    protected function execute(InputInterface $input, OutputInterface $output): int
    {
        echo 'Hello World! '.$input->getOption('option1').' '.$input->getArgument('argument1');

        return self::SUCCESS;
    }
}

NB : en SF < 6.1, remplacer l'attribut AsCommand par une propriété connue de la classe mère :

   protected static $defaultName = 'app:ma_commande';

Pour définir un argument tableau, utiliser InputArgument::IS_ARRAY et séparer les valeurs par un espace. Ex :

 bin/console app:my_command arg1.1 arg1.2 arg1.3

Contrôleurs

Les contrôleurs Symfony sont les classes qui définissent les opérations à réaliser quand on visite les pages du sites : elles transforment une requête HTTP en réponse (JSON ou XML).

Par convention, leurs noms se terminent par Controller, les noms de leurs méthodes se terminent par "Action", et les URL qui provoquent leurs exécutions sont définies dans leurs annotations. L'exemple suivant affiche un texte quand on visite l'adresse "/" ou "/helloWorld" :

class HelloWorldController extends AbstractController
{
    #[Route(path: '/', name: 'helloWorld')]
    #[Route(path: '/helloWorld', name: 'helloWorld')]
    public function indexAction(Request $request): Response
    {
        return new Response('Hello World!');
    }
}

NB : en PHP < 8, remplacer l'attribut par une annotation :

   /**
    * @Route("/", name="helloWorld")
    * @Route("/helloWorld")
    */

Retours

Ces méthodes peuvent déboucher sur plusieurs actions :

• Response() : affiche un texte, et facultativement un code HTTP en deuxième paramètre (ex : erreur 404).
• JsonResponse() ou $this->json() : affiche du JSON.
• RedirectResponse() : renvoie vers une autre adresse. Si elle se trouve dans la même application, on peut aussi utiliser le $this->forward() hérité du contrôleur abstrait.
• $this->redirect('mon_url') : redirige à une autre adresse.
• $this->redirectToRoute('nom_de_la_route'); : redirige vers une route du site par son nom.
• $this->generateUrl('app_mon_chemin', []); : redirige vers une URL relative (ajouter UrlGeneratorInterface::ABSOLUTE_URL en paramètre 3 pour l'absolue, car il est à UrlGeneratorInterface::ABSOLUTE_PATH par défaut dans SF3).
• $this->container->get('router')->generate('app_mon_chemin', ['paramètre' => 'mon_paramètre']);.
• $this->render() : affiche une page à partir d'un template, par exemple HTML ou Twig.

Flashbag

On peut aussi ajouter un bandeau de message temporaire en en-tête via :

$this->addflash('success', 'mon_message');

Le Twig peut les récupérer ensuite avec :

 {% for flashMessage in app.session.flashbag.get('success') %}
    {{ flashMessage }}
 {% endfor %}

En effet, ils sont stockés dans un Flashbag : un objet de session.

De plus, il en existe plusieurs types (chacun avec une couleur) : success, notice, info, warning, error.

Accès aux paramètres et services

Les contrôleurs étendent la classe abstraite Symfony\Bundle\FrameworkBundle\Controller\AbstractController. Cela leur permettait entre autres dans Symfony 2, de récupérer les services et paramètres ainsi :

dump($this->get('session'));
dump($this->getParameter('kernel.project_dir'));

Depuis Symfony 4, il faut injecter le service service_container pour accéder à la liste des services publiques (public: true en YAML), mais la bonne pratique est d'injecter uniquement les services nécessaires dans le constructeur.

Les paramètres sont ceux des fichiers .yml du dossier "config", mais plusieurs autres paramètres sont fournis par Symfony :

bin/console debug:container --parameters

• kernel.debug : renvoie vrai si le site est en préprod et faux en prod.
• kernel.project_dir : dossier racine (qui contient bin/, config/, src/, var/, vendor/).
• kernel.build_dir.
• kernel.cache_dir.
• kernel.logs_dir.
• kernel.root_dir : deprecated en SF5.3. Chemin du site dans le système de fichier.
• kernel.bundles : liste JSON des bundles chargés.

Routing

Par exemple pour créer une nouvelle page sur l'URL :

http://localhost:8000/test

Installer le routage :

composer require sensio/framework-extra-bundle
composer require symfony/routing

Par défaut, la page renvoie l'exception No route found for "GET /test". Pour la créer, il faut d'abord générer un fichier contrôleur (rôle MVC), qui fera le lien entre les URL, les données (modèle) et les pages (vue).

Les URL définies dans l"annotation "@Route" d'une méthode exécuteront cette dernière :

<?php
namespace AppBundle\Controller;

use Sensio\Bundle\FrameworkExtraBundle\Configuration\Route;
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\Response;

class TestController extends AbstractController
{
    #[route('/test/{numero}', name: 'test', requirements: ['id' => '\d*'], methods: ['GET', 'POST'], priority: -1)]
    public function HelloWorldAction(int $numero = 0)
    {
        return new Response('Hello World! '.$numero);
    }
}

NB : en PHP < 8, remplacer l'attribut par une annotation :

   /**
    * @Route("/test/{numero}", name="test", requirements={"id"="\d*"}, methods={"GET|POST"}, priority=-1)
    */

Autres exemples de prérequis :

• requirements={"id"="fr|en"}
• requirements={"id"="MaClasse::MA_CONSTANTE1|MaClasse::MA_CONSTANTE2"}
• requirements={"id"="(?!api/doc|_profiler).*"}

Alias

Pour créer des alias, c'est-à-dire plusieurs autres URL pointant vers la page ci-dessus, on peut l'ajouter dans les annotations des contrôleurs, ou bien dans config/routes.yaml (anciennement app\config\routing.yml sur Symfony < 4) :

test:
    path:      /test/{numero}
    defaults:  { _controller: AppBundle:Test:HelloWorld }

À présent http://localhost:8000/test/1 ou http://localhost:8000/test/2 affichent "Hello World!".

• Une fois le YAML sauvegardé, l'URL fournie en annotation (/test) ne fonctionne plus.
• S'il y a des annotations précédant @Route dans le même bloc, cela peut inhiber son fonctionnement.

Redirection vers la dernière page visitée

Une astuce pour rediriger l'utilisateur vers la dernière page qu'il avait visité :

$router = $this->get('router');
$lastPage = $request->getSession()->get('last_view_page');
$parameterLastPage = $router->match($lastPage);
$routeLastPage = $parameterLastPage['_route'];
unset($parameterLastPage['_route']); // Pour ne pas la voir dans l'URL finale
return $this->redirect(
   $this->generateUrl($routeLastPage, $parameterLastPage)
);

Annotations.yaml

Ce fichier permet de définir des groupes de contrôleurs, dont les routes sont préfixées. Ex :

back_controllers:
    resource: ../../src/Controller/BackOffice
    type: annotation
    prefix: admin

front_controllers:
    resource: ../../src/Controller/FrontOffice
    type: annotation
    prefix: api

Dans le cas où les contrôleurs ont des contrôles d'accès différents dans security.yaml, il est impératif de les préfixer ainsi pour éviter toute collision des gardiens.

 security.yaml utilise les voteurs : des classes qui écoutent des évènements pour vérifier les permissions de l'utilisateur logué.

Paramètres spéciaux

Il existe quatre paramètres spéciaux que l'on peut placer dans routes.yaml ou en argument des méthodes des contrôleurs :

• _controller : contrôleur appelé par le chemin.
• _ format : format de requête (ex : html, xml).
• _fragment : partie de l'URL après "#".
• _locale : langue de la requête (code ISO, ex : fr, en).

Exemple :

#[Route('/controller_route', requirements: ['_locale' => 'en|fr'])]
class MyController extends AbstractController

Vue

Pour commencer à créer des pages plus complexes, il suffit de remplacer :

 return new Response('Hello World!');

par une vue issue d'un moteur de template. Celui de Symfony est Twig :

 return $this->render('helloWorld.html.twig');

Pour installer les bibliothèques JavaScript qui agiront sur ces pages, se positionner dans /public. Exemple :

cd public/
sudo apt-get install npm
npm install --save jquery
npm install --save bootstrap

Ensuite il suffit de les appeler dans /templates/helloWorld.html.twig pour pouvoir les utiliser :

<link rel="stylesheet" href="{{ asset('node_modules/bootstrap/dist/css/bootstrap.min.css') }}">

<script type="text/javascript" src="{{ asset('node_modules/jquery/dist/jquery.min.js') }}"></script>
<script type="text/javascript" src="{{ asset('node_modules/bootstrap/dist/js/bootstrap.min.js') }}"></script>

Modèle

Pour gérer le modèle du MVC, c'est-à-dire la structure des données stockées, l'ORM officiel de Symfony se nomme Doctrine.

Par défaut, ses classes sont :

• src/Entity : les entités, reflets des tables.
• src/Repository : les requêtes SELECT SQL (ou find MongoDB).

Références

• « Wiki officiel »
• « Tutoriel openclassrooms.com »
• « Tutoriel developpez.com »
• (en) « Symfony 3.1 cookbook » : livre officiel de 500 pages
• (en) « Charming Development in Symfony 5 » (texte et vidéo)

Voir aussi

• #symfony : canal IRC (#symfony sur Freenode)
• #symfony-fr : canal IRC francophone (#symfony-fr sur Freenode)
• https://sonata-project.org/get-started : un CMS basé sur Symfony

Service

Le principe des services Symfony est d'éviter d'instancier la plupart des classes avec des "new" dispersés dans le code, pour les déclarer une seule fois, grâce au container. Ils sont alors instanciés uniquement s'ils sont utilisés (ex : sur la page web courante), grâce au lazy loading du container.

Cette déclaration peut se faire en PHP, en YAML ou en XML. On baptise alors le service (il peut y en avoir plusieurs par classe), et on appelle ses arguments par leur nom de service. Exemple :

services:
    app.my_namespace.my_service:
        class: App\myNamespace\myServiceClass
        arguments:
            - '%parameter%'
            - '@app.my_namespace.my_other_service'

Autowiring

Avant SF2.8, il était obligatoire de déclarer chaque service dans les fichiers de configuration .yml ou .yaml, en plus de leurs classes .php (qui peuvent se contredire), et de les mettre à jour à chaque changement de structure.

Depuis SF2.8, l'"autoconfigure: true" permet de déclarer automatiquement chaque service à partir de sa classe, et l'"autowiring: true" d'injecter automatiquement les arguments connus (ex : une autre classe appelée par son espace de nom et son nom), donc sans déclaration manuelle.

Depuis SF4, cette déclaration est par défaut sans le fichier services.yaml, mais on peut la placer dans un autre fichier qui sera importé par le premier, par exemple avec :

imports:
    - { resource: services1.yaml }
    - { resource: services2.yaml }

ou :

imports:
    - { resource: services/* }

Cette séparation des services en plusieurs .yaml nécessite par contre d'exclure les dossiers de ces services de l'autowiring, et de reprendre la section _defaults dans le nouveau .yaml.

Exemple d'exclusion récursive de plusieurs dossiers de même nom, avec ** :

    App\:
        resource: '../src/*'
        exclude:
            - '../src/UnDossier'
            - '../src/**/Entity' # Tous les sous-dossiers "Entity"

bind

Par défaut, l'autowiring ne fonctionne pas avec les classes avec des tags, ou ayant autre chose que des services dans leurs constructeurs. Néanmoins pour injecter des scalaires automatiquement, il suffit que ces derniers soit déclarés aussi. Ex :

services:
    _defaults:
        bind:
            $salt: 'ma_chaine_de_caractères'
            $variableSymfony: '%kernel.project_dir%'
            $variableDEnvironnement: '%env(resolve:APP_DEBUG)%'

_instanceof

Pour ajouter un tag ou injecter un service si on implémente une interface. Ex :

services:
    _instanceof:
        Psr\Log\LoggerAwareInterface:
            calls:
                  - [ 'setLogger', [ '@logger' ] ]

Ici, toutes les classes qui implémentent LoggerAwareInterface verront leurs méthodes setLogger(LoggerInterface $logger) appelées automatiquement à l’instanciation.

En SF2

Les contrôleurs ne sont pas des services mais peuvent les appeler avec la méthode :

$this->get('app.my_namespace.my_service')

Pour déterminer si un service existe depuis un contrôleur :

$this->getContainer->hasDefinition('app.my_namespace.my_service')

Pas de require_once()

Les classes natives de PHP doivent être introduites par leur namespace ou bien par l'espace de nom global. Ex :

use DateTime;
echo new DateTime();

ou

echo new \DateTime();

Paramètres

Chaque service doit donc être déclaré avec un paramètre "class", puis peut ensuite facultativement contenir les paramètres suivants :

Paramètres des services en YAML

Nom	Rôle
class	Nom de la classe instanciée par le service.
arguments	Tableau des arguments du constructeur de la classe, services ou variables.
calls	Tableau des méthodes de la classe à lancer après l'instanciation, généralement des setters.
factory	Instancie la classe depuis une autre classe donnée. Méthode statique de la classe qui sera renvoyée par le service.
configurator	Exécute un invocable donné après l'instanciation de la classe.
alias	Crée un autre nom pour un service, qui peut alors être modifié par d'autres paramètres de déclaration (ex : créer une version publique d'un service privé dans services_test.yaml).
parent	Nom de la superclasse.
abstract	Booléen indiquant si la méthode est abstraite.
public	Booléen indiquant une portée publique du service.
shared	Booléen indiquant un singleton.
tags	Quand on doit injecter un nombre indéterminé de services dans un autre, il est possible de le définir avec chacun des services à injecter, en y ajoutant un tag avec le nom du service qui peut les appeler. Ce tag doit néanmoins être défini dans un CompilerPass.
autowire	Booléen vrai par défaut, spécifiant si le framework doit injecter automatiquement les arguments du constructeur.
decorates	Remplace un service par sa version décorée (mais l'ancien est toujours accessible an ajoutant le suffixe .inner au service décorateur)

Injecter des services tagués

Dans un constructeur :

    App\Service\FactoriesHandler:
        arguments:
            - !tagged_iterator app.factory

Dans une autre méthode :

    App\Service\FactoriesHandler:
        calls:
            - [ 'setFactories', [!tagged_iterator app.factory] ]

Par défaut, l'itérateur contient des clés numériques, mais on peut les personnaliser. Ex :

    App\Factory\FactoryOne:
        tags:
            - { name: 'app.factory', my_key: 'factory_one' }

    App\Service\FactoriesHandler:
        arguments:
            - !tagged_iterator { tag: 'app.factory', key: 'my_key' }

Service abstrait

Un service abstrait est un système de factorisation des injections par l'intermédiaire d'une classe abstraite. Par exemple si on veut que tous les contrôleurs héritent du service logger (comme l'exemple _instanceof ci-dessus), plus la méthode setLogger() de leur classe abstraite, sans avoir à toucher à leurs constructeurs :

    App\Controller\:
        resource: '../src/Controller'
        parent: App\Controller\AbstractEntitiesController
        tags: ['controller.service_arguments']

    App\Controller\AbstractEntitiesController:
        abstract: true
        autoconfigure: false
        calls:
            - [ 'setLogger', [ '@logger' ] ]

Composant

Description

Le framework Symfony permet nativement les fonctionnalités minimum dans un souci de performances, à l'instar d'un micro-framework. Par exemple son compilateur permet d'utiliser plusieurs patrons de conception (design patterns) via des mots réservés dans services.yaml :

• arguments : Injection de dépendance
• decorator : Décorateur.
• shared : Singleton.
• factory : Fabrique.

Toutefois, on peut lui ajouter des composants, dont il convient de connaitre les fonctionnalités pour ne pas réinventer la roue. Pour les installer :

composer require symfony/nom_du_composant

Les quatre premiers ci-dessous sont inclus par défaut dans le microframework symfony/skeleton.

framework-bundle

Structure la configuration principale du framework sans laquelle aucun composant n'est installable.

console

Patrons de conception "Commande".

Fournit la possibilité d'exécuter le framework avec des commandes shell. Par exemple pour obtenir la liste de toutes les commandes disponibles dans un projet :

php bin/console help list

dotenv

Gère les variables d'environnement non versionnées, contenues dans un fichier .env. Elles peuvent aussi bénéficier de type checking en préfixant les types avec ":". Ex de .env :

IS_DEV_SERVER=1

Le services.yaml, parameters: récupère ensuite cette valeur et vérifie qu'il s'agit d'un booléen (via le processeur de variable d'environnement "bool") :

is_dev_server: '%env(bool:IS_DEV_SERVER)%'

Il existe plusieurs processeurs de variable d'environnement (en plus de "bool" et des autres types) :

• base64: encode en base64.
• default: remplace le deuxième paramètre par le premier si absent. Ex :
  • $addTestValues: '%env(bool:default::ADD_TEST_VALUES)%' injecte "null" si ADD_TEST_VALUES n'est pas défini.
  • $addTestValues: '%env(bool:default:ADD_TEST_VALUES2:ADD_TEST_VALUES1)%' injecte le contenu de ADD_TEST_VALUES2 si ADD_TEST_VALUES1 n'est pas défini.
• file: remplace le chemin d'un fichier par son contenu.
• not: renvoie l'inverse.
• require: fait un require() PHP.
• resolve: remplace le nom d'une variable par sa valeur.
• trim: fait un trim() PHP.

Pour définir une valeur par défaut en cas de variable d'environnement manquante (sans utiliser default:), dans services.yaml, parameters: :

env(MY_MISSING_CONSTANT): '0'

yaml

Ajoute la conversion de fichier YAML en tableau PHP. Ce format de données constitue une alternative plus lisible au XML pour renseigner la configuration des services. Par défaut le framework se configure avec config.yaml.

routing

patron de conception "Façade".

Installe les annotations permettant de router des URLs vers les classes des contrôleurs MVC.

Pour plus de détails voir : Programmation PHP/Symfony#Routing.

serializer

Permet de convertir des objets en tableaux ou dans les principaux formats de notation : JSON, XML, YAML et CSV.

 composer require symfony/serializer

Ce composant est notamment utilisé pour créer des APIs.

form

Construit des formulaires HTML.

Pour plus de détails voir : Programmation PHP/Symfony/Formulaire.

validator

Fournit des règles de validation pour les données telles que les adresses emails ou les codes postaux. Utile à coupler avec les formulaires pour contrôler les saisies.

Ces règles peuvent porter sur les propriétés ou les getters.

Il permet aussi de créer des groupes de validateurs, et de les ordonner par séquences. Par défaut chaque classe a automatiquement deux groupes de validateurs : "default" et celui de son nom. Si une séquence est définie, le groupe "default" n'est plus égal au groupe de la classe (celui par défaut) mais à la séquence par défaut.

translation

Module de traductions dans des fichiers contenant le ISO 639-1 de chaque langue du projet. Par défaut le français est dans translations/messages.fr.yml. On peut ensuite récupérer ces dictionnaires en Twig, ou en PHP via le service "translator".

Pour avoir les traductions inutilisées en anglais :

bin/console debug:translation en --only-unused

Pour les traductions manquantes en anglais :

bin/console debug:translation en --only-missing

event-dispatcher

Patrons de conception "Observateur" et "Médiateur".

Assure la possibilité d'écouter des évènements pour qu'ils déclenchent des actions.

Pour plus de détails voir : Programmation PHP/Symfony/Évènement.

process

Permet de lancer des sous-processus en parallèle. Exemple qui lance une commande shell :

    $process = new Process(['ls']);
    $process->run();

En l'absence de $process->stop() ou de timeout, le sous-processus peut être stoppé en redémarrant le serveur PHP.

Exemple de requête SQL asynchrone :

        $sql = 'SELECT * FROM ma_table LIMIT 1';
        $process = Process::fromShellCommandline(sprintf('../bin/console doctrine:query:sql "%s"', $sql));
        $process->setTimeout(3600);
        $process->start();

cache

Gère les connexions, lectures et écritures vers des serveurs de mémoire caches tels que Redis ou Memcached.

Il fournit une classe cacheItem conforme à la PSR, instanciable par plusieurs adaptateurs.

asset

Ajoute la fonction Twig asset() pour accéder aux fichiers CSS, JS ou images selon leurs versions.

webpack-encore

Intégration de Webpack pour gérer la partie front end (ex : minifications des CSS et JS).

Installation :

composer install encore
yarn install
yarn build

NB : si yarn n'est pas installé, le faire avec apt install nodejs npm; npm install --global yarn.

Cela crée les fichiers package.json et yarn.lock contenant les dépendances JavaScript, le dossier assets/ contenant les JS et CSS versionnés, et le fichier webpack.config.js dans lequel ils sont appelés.

De plus, des fonctions Twig permettent d'y accéder depuis les templates : encore_entry_link_tags() et encore_entry_script_tags().

Par ailleurs, cela installe le framework JS Stimulus, et interprète les attributs de données pour appeler ses contrôleurs ou méthodes.

messenger

Patrons de conception "Chaîne de responsabilité".

Messenger permet d'utiliser des queues au protocole AMQP. En résumé, il gère l'envoi de messages dans des bus, ces messages transitent par d'éventuels middlewares puis arrivent à destination dans des handlers. On peut aussi persister ces messages en les envoyant dans des transports via un DSN, par exemple dans RabbitMQ, Redis ou Doctrine (donc une table des SGBD les plus populaires).

 php bin/console debug:messenger

Chaque middleware doit passer le relais au suivant ainsi :

return $stack->next()->handle($envelope, $stack);

Pour stopper le message dans un middleware sans qu'il arrive aux handlers :

return $envelope;

workflow

Patrons de conception "État".

Ce composant nécessite de créer (en YAML, XML ou PHP) la configuration d'un automate fini, c'est-à-dire la liste de ses transitions et états (appelés "places").

Ces graphes sont ensuite visualisables en image ainsi :

use Symfony\Component\Workflow\Definition;
use Symfony\Component\Workflow\Dumper\StateMachineGraphvizDumper;

class WorkflowDisplayer
...
$definition = new Definition($places, $transitions);
echo (new StateMachineGraphvizDumper())->dump($definition);

sudo apt install graphviz
php WorkflowDisplayer.php | dot -Tpng -o workflow.png

browser-kit

Simule un navigateur pour les tests d'intégration.

config

Permet de manipuler des fichiers de configurations.

contracts

Pour la programmation par contrat.

css-selector

Pour utiliser XPath.

debug

Fournit des méthodes statiques pour déboguer le PHP.

dependency-injection

Normalise l'utilisation du container de services.

Permet aussi d'exécuter du code pendant la compilation via un compiler pass, en implémentant l'interface CompilerPassInterface avec sa méthode process.

dom-crawler

Fournit des méthodes pour parcourir le DOM.

expression-language

Patrons de conception "Interpréteur".

Expression language sert à évaluer des expressions, ce qui peut permettre de définir des règles métier.

Installation :

composer require symfony/expression-language

Exemple :

$el = new ExpressionLanguage();
$operation = '1 + 2';
echo(
    sprintf(
        "L'opération %s vaut %s",
        $el->compile($operation));
        $el->evaluate($operation));
    )
);
// Affiche : L'opération 1 + 2 vaut 3

filesystem

Méthodes de lecture et écriture dans les dossiers et fichiers.

finder

Recherche dans les dossiers et fichiers.

security

Ensemble de sous-composants assurant la sécurité d'un site. Ex : authentification, anti-CSRF ou droit des utilisateurs d'accéder à une page.

Dans security.yaml, on peut par exemple définir les classes qui vont assurer l'authentification (guard), ou celle User qui sera instanciée après.

Pour obtenir l'utilisateur ou son token, on peut injecter :

TokenStorageInterface $tokenStorage

pour avoir l'utilisateur courant avec $this->tokenStorage->getToken()->getUser().

guard

Extension de sécurité pour des authentifications complexes.

http-client

Pour lancer des requêtes HTTP depuis l'application.

Pour plus de détails voir : Programmation PHP/Symfony/HttpClient.

http-foundation

Fournit des classes pour manipuler les requêtes HTTP, comme Request et Response que l'on retrouve dans les contrôleurs.

Par exemple :

use Symfony\Component\HttpFoundation\Response;
//...
echo Response::HTTP_OK; // 200
echo Response::HTTP_NOT_FOUND; // 404

http-kernel

Permet d'utiliser des évènements lors des transformations des requêtes HTTP en réponses.

inflector

Deprecated depuis Symfony 5.

Accorde les mots anglais au pluriel à partir de leurs singuliers.

intl

Internationalisation, comme par exemple la classe "Locale" pour gérer une langue.

ldap

Connexion aux serveur LDAP.

lock

Pour verrouiller les accès aux ressources.

mailer

Pour envoyer des emails.

mime

Manipulation des messages MIME.

notifier

Pour envoyer des notifications telles que des emails, des SMS, des messages instantanés, etc.

options-resolver

Gère les remplacements de propriétés par d'autres, avec certaines par défaut.

phpunit-bridge

Patron de conception "Pont" qui apporte plusieurs fonctionnalités liées aux tests unitaires, telles que la liste des tests désuets ou des mocks de fonctions PHP natif.

property-access

Pour lire les attributs de classe à partir de leurs getters, ou des tableaux.

property-info

Pour lire les métadonnées des attributs de classe.

stopwatch

Chronomètre pour mesurer des temps d'exécution.

string

API convertissant certains objets en chaine de caractères. Ex :

use Symfony\Component\String\Slugger\AsciiSlugger;

$slugger = new AsciiSlugger();
echo $slugger->slug('caractères spéciaux € $');

Résultat :

caracteres-speciaux-EUR

templating

Extension de construction de templates.

Pour plus de détails voir : Programmation PHP/Symfony/Templating.

var-dumper

Ajoute une fonction globale dump() pour déboguer des objets en les affichant avec une coloration syntaxique et des menus déroulant.

Ajoute aussi dd() pour dump() and die().

var-exporter

Permet d'instancier une classe sans utiliser son constructeur.

polyfill*

On trouve aussi une vingtaine de composants polyfill, fournissant des fonctions PHP retirées dans les versions les plus récentes.

Composants désuets

locale (<= v2.3)

Arrêté en 2011, car remplacé par le composant intl.

icu (<= v2.6)

Arrêté en 2014, car remplacé par le composant intl.

class-loader (<= v3.3)

Arrêté en 2011, car remplacé par composer.json.

Ajoutés en 2020

Uid (sic) (>= v5.1)

Pour générer des UUID.

RateLimiter (>= v5.2)

Patron de conception "Proxy", qui permet de limiter la consommation de ressources du serveur par les clients

Semaphore (>= v5.2)

Pour donner l'exclusivité d'accès à une ressource.

Ajoutés en 2021

PasswordHasher (>= v5.3)

Pour gérer les chiffrements.

Runtime (>= v5.3)

Pour le démarrage (bootstrap) : permettre de découpler l'application de son code de retour. .

Ajoutés en 2022

Symfony UX (>= v5.4)

ux-chartjs

Utilise Chart.js via Stimulus pour afficher des graphiques, via la fonction Twig render_chart().

ux-react

Ajoute le framework React.js.

ux-vue

Ajoute le framework Vue.js.

Composants non listés comme tels

apache-pack

Pour faire tourner le site sans passer par le serveur symfony server:start.

HttpClient

Installation

Composant pour lancer des requêtes HTTP depuis l'application, avec gestion des timeouts, redirections, cache, protocole et en-tête HTTP. Il est configurable en PHP ou dans framework.yaml.

Depuis Symfony 4 :

Terminal

composer require symfony/http-client

Utilisation

Par défaut, l'appel statique à la classe HttpClient instancie un CurlHttpClient, alors que l'injection du service via HttpClientInterface récupère un TraceableHttpClient :

HttpClient::create();
__construct(HttpClientInterface $httpClient)

GET

On peut forcer l'utilisation de HTTP 2 à la création :

        $httpClient = HttpClient::create(['http_version' => '2.0']);
        $response = $httpClient->request('GET', 'https://fr.wikibooks.org/');
        if (200 == $response->getStatusCode()) {
            dd($response->getContent());
        } else {
            dd($response->getInfo('error'));
        }

Ce code ne lève pas les exceptions de résolution DNS.

POST

Exemple en POST avec authentification :

        $response = $httpClient->request('POST', 'https://fr.wikibooks.org/w/api.php', [
            'auth_bearer' => 'mon_token',
            'jsonA' => $keyValuePairs,
        ]);

Pour lancer plusieurs appels asynchrones, il suffit de placer leurs $response->getContent() ensemble, après tous les $httpClient->request().

Pour envoyer un fichier il y a plusieurs solutions :

• Utiliser le type MIME correspondant à son extension (ex : 'application/pdf', 'application/zip'...). Mais on ne peut envoyer que le fichier dans la requête.
• Utiliser le type MIME 'application/json' et l'encoder en base64. Il peut ainsi être envoyé avec d'autres données.
• Utiliser le type MIME 'multipart/form-data'.

Problèmes connus

Ce composant est relativement jeune et souffre d'incomplétudes.

• On peut avoir du "null given" à tort sur un mapping DNS, solvable en rajoutant une option :

        $options = array_merge($options, [
            'resolve' => ['localhost' => '127.0.0.1']
        ]);

• $httpClient->request() renvoie une Symfony\Contracts\HttpClient\ResponseInterface, mais en cas d'erreur, elle ne contient qu'une ligne de résumé, soit moins d'informations qu'un client comme Postman.

Tests

Ce composant peut aussi serveur aux tests fonctionnels via PhpUnit. On l'appelle alors avec static::createClient si le test extends WebTestCase. Dans le cas d'un projet API Platform, on l'appelle de la même manière mais le test extends ApiTestCase.

Exemple :

$client = static::createClient();
$client->request('GET', '/home');
var_dump($client->getResponse()->getContent());

Pour simuler plusieurs clients en parallèle : $client->insulate().

Pour simuler un utilisateur : $client->loginUser($monUser).

Pour un test de bundle, il faut créer une classe Kernel qui charge les routes en plus.

Évènement

Un évènement est une action pouvant en déclencher d'autres qui l'attendaient, à la manière du patron de conception observateur, via un hook.

Installation

Terminal

composer require symfony/event-dispatcher

Commande

Pour lister les évènements et écouteurs d'un projet (avec leurs priorités) :

 php bin/console debug:event-dispatcher

Ex :

"console.terminate" event
-------------------------

 ------- ----------------------------------------------------------------------------- ----------
  Order   Callable                                                                      Priority
 ------- ----------------------------------------------------------------------------- ----------
  #1      Symfony\Component\Console\EventListener\ErrorListener::onConsoleTerminate()   -128
  #2      Symfony\Bridge\Monolog\Handler\ConsoleHandler::onTerminate()                  -255
 ------- ----------------------------------------------------------------------------- ----------

Event

Pour utiliser ce système, la première étape consiste à déterminer si on souhaite utiliser un évènement existant, ou en créer un nouveau.

• Pour un existant, son nom est obtenu par le commande ci-dessus.
• Pour un nouveau, voici un exemple de conception pilotée par le domaine où l'on souhaite qu'une condition du core soit traitée dans des modules en fonction du groupe utilisateur, sans les lister dans le core :

class AddExtraDataEvent
{
    /** @var string */
    private $userGroup;

    public function __construct(string $userGroup)
    {
        $this->userGroup = $userGroup;
    }

    public function getUserGroup(): string
    {
        return $this->usernGroup;
    }

    public function setUserGroup(string $usernGroup): AddExtraDataEvent
    {
        $this->userGroup = $userGroup;

        return $this;
    }
}

Une fois la classe crée, il faut choisir où l'instancier :

use Symfony\Component\EventDispatcher\EventDispatcher;
...
$this->eventDispatcher->dispatch(new AddExtraDataEvent($userGroup));

 le setter permet de transférer un résultat issu des observateurs de l’évènement, à l'endroit qui les dispatch (qu'il peut récupérer via le getter de l'évènement). Une alternative serait d'injecter à la place de EventDispatcher, un tableau des services des modules concernés, définis par un tag.

Listener

Pour exécuter une ou plusieurs classes au moment du dispatch, il faut créer maintenant en créer une qui écoute l'évènement. Elle doit peut être reliée à son évènement, soit dans sa déclaration de service pour un écouter (event listener), soit dans son constructeur pour un souscripteur (event subscriber).

Le listener a donc l'inconvénient de devoir être déclaré avec un tag, alors que le subscriber lui, est chargé à chaque exécution du programme, ce qui alourdit légèrement les performances mais évite de maintenir sa déclaration en autowiring.

Exemple de déclaration YAML

services:
    App\EventListener\MyViewListener:
        tags:
            - { name: kernel.event_listener, event: kernel.view }

class MyViewListener
{
    public function onKernelException(ExceptionEvent $event)
    {
        echo "Triggered!";
    }
}

Subscriber

Un souscripteur doit forcément implémenter EventSubscriberInterface :

class ViewSubscriber implements EventSubscriberInterface
{
    public function getSubscribedEvents(): array
    {
        return [
            KernelEvents::VIEW => ['onView']
        ];
    }

    public function onView(ViewEvent $event): void
    {
        echo "Triggered!";
    }
}

Autre exemple où on veut embarquer dans un évènement maison une information de ses souscripteurs :

class ClientXUserSubscriber implements EventSubscriberInterface
{
    ...
    public static function getSubscribedEvents(): array
    {
        return [
            ClientXEvent::class => 'getProperty',
        ];
    }

    public function getProperty(ClientXUserEvent $event): void
    {
        if ('X' === $this->user->getCompany()) {
            $event->setProperty('XX');
        }
    }
}

Débogage

Les erreurs qui surviennent selon certains évènements ne sont pas faciles à provoquer ou visualiser. Pour les voir sans passer par le profiler, on peut ajouter temporairement dans un contrôleur :

$this->getEventDispatcher()->dispatch('mon_service');

Formulaire

Principe

Le principe est d'ajouter des champs de formulaire en PHP, qui seront automatiquement convertis en code HTML correspondant.

En effet, comme vu dans le [[../../Formulaire|chapitre sur les formulaire PHP]], en HTML on utilise habituellement la balise <form> pour afficher les champs à remplir par le visiteur. Puis sur validation on récupère leurs valeurs en PHP avec la superglobale $_REQUEST (ou ses composantes $_GET et $_POST). Or ce système ne fonctionne pas en $_POST dans Symfony : si on affiche un tel formulaire et qu'on le valide, $_POST est vide, et l'équivalent Symfony de $_REQUEST, $request->request aussi.

Les formulaires doivent donc nécessairement être préparés en PHP.

Installation

Form

Terminal

 composer require symfony/form

Les formulaires présents sont ensuite listables avec :

Terminal

 bin/console debug:form

Et vérifiables individuellement :

Terminal

 bin/console debug:form "App\Service\Form\MyForm"

Avec le composant maker, on peut créer un formulaire pour chaque entité Doctrine à modifier :

Terminal

 composer require symfony/maker-bundle
 bin/console make:form

Validator

Pour ajouter des contrôles sur les champs, il existe un deuxième composant Symfony :

Terminal

 composer require symfony/validator

Contrôleur

Injection du formulaire dans un Twig

class HelloWorldType extends AbstractType
{
    public function buildForm(FormBuilderInterface $builder, array $options): void
    {
        $builder
            ->add('name', TextType::class)
            ->add('save', SubmitType::class)
        ;
    }
}

class HelloWorldController extends AbstractController
{
    #[Route('/helloWorld/{id}, requirements: ['id' => '\d*']')]
    public function indexAction(Request $request, ?HelloWorld $helloWorld = null): Response
    {
        $form = $this->createForm(HelloWorldType::class, $helloWorld);

        return $this->render('helloWorld.html.twig', [
            'form' => $form->createView(),
        ]);
    }
}

Le second paramètre de createForm() est facultatif est sert à préciser des valeurs initiales dans le formulaire qui seront injectées en Twig, mais elles peuvent aussi l'être via le fichier du formulaire dans les paramètres de chaque champ.

Traitement post-validation

Dans la même méthode du contrôleur qui injecte le formulaire, il faut prévoir le traitement post-validation. Par exemple pour mettre à jour l'entité en base :

    $form->handleRequest($request);
    if ($form->isSubmitted() && $form->isValid()) {
        $email = $form->get('email')->getData();
        $this->em->persist($email);
        $this->em->flush();
        return $this->redirectToRoute('home');
    }

Fichier du formulaire

Dans SF4, l'espace de nom Symfony\Component\Form\Extension\Core\Type propose 35 types de champ, tels que :

• email (avec validation en option de la présence d'arrobase ou de domaine).
• submit (bouton).
• date.

Exemple :

    public function buildForm(FormBuilderInterface $builder, array $options)
    {
        $builder
            ->add('email', 'text', [
                'required' => true,
                'empty_data' => 'valeur par défaut si vide à la validation',
                'data' => 'valeur par défaut préremplie à la création',
                'constraints' => [new Assert\NotBlank()],
                'attr' => ['class' => 'ma_classe_CSS'],
        ]);
    }

Pour préremplir des valeurs dans les champs :

    $form->get('email')->setData($user->getEmail());

L'attribut "required" peut être interprété par les navigateurs comme un "NotBlank", mais il faut tout de même le compléter avec la contrainte sans quoi un simple retrait du "required" de la page web par la console du navigateur pourrait contourner l'obligation.

EntityType

De plus, en installant Doctrine, il est possible d'ajouter un type de champ "entité" directement relié avec un champ de base de données.

Ex :

$builder->add('company', EntityType::class, ['class' => Company::class]);

Il n'y a pas de type Checkbox ou Radiobox comme mais il faut jouer sur deux paramètres de EntityType ainsi :

Élément	Expanded	Multiple
Sélecteur	false	false
Sélecteur multiple	false	true
Boutons radio	true	false
Cases à cocher	true	true

Exemple :

    $builder->add('gender', EntityType::class, ['expanded' => true, 'multiple' => false]);

Validation

Validation depuis les entités

Le validateur de formulaire d'entité peut utiliser les annotations des entités. Ex :

use Symfony\Component\Validator\Constraints as Assert;
...
#[Assert\Type('string')]
#[Assert\NotBlank]
#[Assert\Length(
        min: 1,
        max: 255,
)]

En PHP < 8 :

use Symfony\Component\Validator\Constraints as Assert;
...
    /**
     * @Assert\Type("string")
     * @Assert\NotBlank
     * @Assert\Length(
     *      min = 2,
     *      max = 50
     * )
     */

Plusieurs types de données sont déjà définis, comme l'email ou l'URL. Ex :

@Assert\Email()

Validation depuis les formulaires

Sinon il permet aussi des contrôles plus personnalisés dans les types (qui étendent Symfony\Component\Form\AbstractType). Ex :

'constraints' => [
    new Assert\NotBlank(),
    new GreaterThanOrEqual(2),
    new Assert\Callback([ProductChecker::class, 'check']),
],

Validation avec un service

Pour valider une entité depuis le service validateur :

use Symfony\Component\Validator\Validator\ValidatorInterface;
...
$validator->validate(
       $entity,
       $entityConstraint
   );

NB : le second paramètre est optionnel.

Bien que l'on voit des services correspondant aux contraintes du validateur, on ne peut pas les injecter comme les autres services mais uniquement les utiliser via le validateur général.

Exemple pour valider un email :

php bin/console debug:container |grep -i validator |grep -i email
  validator.email Symfony\Component\Validator\Constraints\EmailValidator

use Symfony\Component\Validator\Constraints\Email;
use Symfony\Component\Validator\Validator\ValidatorInterface;
...
        $this->validator->validate(
            'mon_email@example.com',
            new Email()
        );

Appel du formulaire Symfony dans la vue

Les fonctions Twig permettant d'ajouter les éléments du formulaire sont :

• form_start
• form_errors
• form_row
• form_widget
• form_label

Pour afficher tout le formulaire, dans l'ordre où les champs ont été définis en PHP :

    {{ form_start(form) }}
    {{ form_end(form) }}

Pour n'afficher qu'un seul champ :

{{ form_widget(form.choosen_credit_card) }}

Les mêmes attributs qu'en PHP peuvent être définis en paramètre. Ex :

{{ form_widget(form.name, {'attr': {'class': 'address', 'placeholder': 'Entrer une adresse'} }) }}
{{ form_label(form.name, null, {'label_attr': {'class': 'address'}}) }}

Exemple complet :

{{ form_start(form) }}
    {{ form_errors(form) }}

    {{ form_label(form.name, 'Label du champ "name" écrasé ici') }}
    {{ form_row(form.name) }}
    {{ form_widget(form.message, {'attr': {'placeholder': 'Remplacez ce texte par votre message'} }) }}

    {{ form_rest(form) }}

    {{ form_row(form.submit, { 'label': 'Submit me' }) }}
{{ form_end(form) }}

Mailer

Mailer

Depuis Symfony 4.3, un composant Symfony Mailer a été ajouté.

Pour l'installer :

Terminal

composer require symfony/mailer

Ajouter ensuite le SMTP dans le .env :

MAILER_DSN=smtp://mon_utilisateur:mon_mot_de_passe@smtp.example.com

Utilisation

    private MailerInterface $mailer;

    public function __construct(MailerInterface $mailer)
    {
        $this->mailer = $mailer;
    }

    public function send(string $message): void
    {
        $email = (new Email())
            ->from('no-reply@example.com')
            ->to('target@example.com')
            ->subject('Test Symfony Mailer')
            ->text($message)
        ;

        $this->mailer->send($email);
    }

Swift Mailer

Avant Symfony 4.3 et la création du composant Mailer, on pouvait utiliser Swift Mailer.

Swift Mailer est ensuite remplacé en novembre 2021 par le composant Mailer.

Installation

Terminal

composer require symfony/swiftmailer-bundle

Utilisation

Par exemple, pour un envoi d'email sans passer par config.yml :

        $transport = (new \Swift_SmtpTransport('mon_smtp.com', 25));
        $mailer = new \Swift_Mailer($transport);
        $message = (new \Swift_Message('Hello World from Controller'))
            ->setFrom('mon_email@example.com')
            ->setTo('mailcatcher@example.com')
            ->setBody('Hello World',
                'text/html'
            )
        ;
        $mailer->send($message);

 il existe des applications comme Mailcatcher pour intercepter les emails envoyés en environnement de développement, et les lire dans une interface graphique.

Templates

Pour simplifier les templates d'email, une alternative au HTML / CSS existe, il s'agit de Inky.

Elle utilise d'autres balises XML, comme callout ou spacer.

Installation :

composer require twig/extra-bundle twig/inky-extra

Utilisation :

{% apply inky_to_html %}
...

Bundles

Dans Symfony, on appelle bundle une bibliothèque prévue pour être installée dans Symfony comme module complémentaire au framework.

Configurer un bundle

Après installation avec composer, il doit généralement être configuré dans le dossier config/ par un fichier YAML à son nom. Pour connaître les configurations possibles :

php bin/console config:dump mon_bundle

La classe du bundle est instanciée dans :

config/bundles.php

Pour l'activer ou le désactiver de certains environnements, il suffit de l'ajouter un paramètre. Ex :

<?php

return [
    // À instancier tout le temps
    Symfony\Bundle\FrameworkBundle\FrameworkBundle::class => ['all' => true],
    // À instancier seulement si dans le .env, APP_ENV=dev ou APP_ENV=test (les autres sont "false" par défaut)
    Symfony\Bundle\WebProfilerBundle\WebProfilerBundle::class => ['dev' => true, 'test' => true],
    // À ne pas instancier dans les environnements de dev
    Sentry\SentryBundle\SentryBundle::class => ['prod' => true],
];

Créer un bundle

Par rapport à une application classique, la création d'un bundle possède des particularités du fait qu'il n'est prévu pour être utilisé que comme dépendance d'applications tierces. Par exemple :

• Ses namespaces doivent démarrer par le nom du vendor et se terminer par le mot Bundle (ex : Symfony\Bundle\FrameworkBundle).
• Il doit contenir un fichier point d'entrée dans sa racine (ex : FrameworkBundle.php).
• Il peut avoir un .yaml de configuration dans config/packages à créer automatiquement à l'installation grâce à une classe étendant ConfigurationInterface.

Principaux bundles

Packagist propose une liste des bundles Symfony les plus utilisés.

SensioFrameworkExtraBundle

Permet de créer des annotations.

FOS

FriendsOfSymfony propose plusieurs bundles intéressants, parmi lesquels :

• FOSUserBundle : pour gérer des utilisateurs.
• FOSRestBundle : pour les API REST.

KNP

KNP Labs offre également plusieurs bundles connus, dont un paginateur.

SonataAdmin

Ce bundle permet de créer rapidement un back-office pour lire ou modifier une base de données.

EasyAdmin

Fonctionnalité filtre de EasyAdminBundle.

Mêmes principales fonctions que SonataAdmin mais plus léger.

Installation :

composer require easycorp/easyadmin-bundle

Pour l'accueil :

bin/console make:admin:dashboard

Pour une liste paginée d'entités Doctrine modifiables, avec liens vers leurs CRUD :

bin/console make:admin:crud

The PHP League

Voir https://github.com/thephpleague.

Twig

Installation

Twig est un moteur de templates pour le langage de programmation PHP, utilisé par défaut par le framework Symfony. Son livre officiel faisant 156 pages, la présente pas aura plutôt un rôle d'aide mémoire et d'illustration.

Pour exécuter du code sans installer Twig, il existe https://twigfiddle.com/.

composer require symfony/templating

Anciennement sur Symfony 3 :

composer require twig/twig

Syntaxe native

Les mots réservés suivants s'ajoutent au HTML déjà interprété :

• {{ ... }} : appel à une variable ou une fonction PHP, ou un template Twig parent ({{ parent() }}).
• {# ... #} : commentaires.
• {% ... %} : commande, comme une affectation, une condition, une boucle ou un bloc HTML.
  • {% set foo = 'bar' %} : assignation.
  • {% if (i is defined and i == 1) or j is not defined or j is empty %} ... {% endif %} : condition.
  • {% for i in 0..10 %} ... {% endfor %} : compteur dans une boucle.
• ' : caractère d'échappement.

Chaines de caractères

Concaténation

Il existe de multiples manière de concaténer des chaines. Ex :

 "{{ variable1 ~ variable2 }}"
 "#{variable1} #{variable2}"

Tableaux

Création

Pour créer un tableau itératif :

{% set myArray = [1, 2] %}

Un tableau associatif :

{% set myArray = {'key': 'value'} %}

À plusieurs lignes :

{% set months = {
    1: 'janvier',
    2: 'février',
    3: 'mars',
} %}
{{ dump(months[1]) }} {# 'janvier' #}

Multidimensionnel :

{% set myArray = [
    {'key1': 'value1'},
    {'key2': 'value2'}
] %}

Dans un "for ... in", pour séparer chaque élément avec une virgule :

{% if loop.first != true %}
    ,
{% endif %}

Pour créer un tableau associatif JavaScript à partir d'un tableau Twig :

<script type="text/javascript">
    const monTableauJs = JSON.parse('{{ monTableauTwig |json_encode |raw }}');

    for (const maLigneJs in monTableauJs) {
        console.log(maLigneJs);
        console.log(monTableauJs[maLigneJs]);
    }
</script>

Modification

Pour ajouter une ou plusieurs lignes à un tableau, utiliser "merge()" :

{% set newArray = oldArray|merge([2,3]) %}

Lecture

Pour savoir si un tableau est vide, utiliser empty comme pour les chaines de caractères. Par exemple pour savoir si un tableau est vide ou null :

my_array is empty

Pour savoir si un élément est dans un tableau :

my_item in my_array

Pour savoir si un élément n'est pas dans un tableau :

my_item not in my_array

Pour savoir si un élément est dans les clés d'un tableau :

my_item in my_array|keys

Pour filtrer le tableau, utiliser filter. Par exemple pour savoir si un tableau multidimensionnel a ses sous-tableaux vides :

my_array|filter(v => v is not empty) is empty

Précédence des opérateurs

Du moins au plus prioritaire :

Opérateur	Rôle
b-and	Et booléen
b-xor	Ou exclusif
b-or	Ou booléen
or	Ou
and	Et
==	Est-il égal
!=	Est-il différent
<	Inférieur
>	Supérieur
>=	Supérieur ou égal
<=	Inférieur ou égal
in	Dans (ex : {% if x in [1, 2] %})
matches	Correspond
starts with	Commence par
ends with	Se termine par
..	Séquence (ex : 1..5)
+	Plus
-	Moins
~	Concaténation
*	Multiplication
/	Division
//	Division arrondie à l'inférieur
%	Modulo
is	Test (ex : is defined ou is not empty)
**	Puissance
|	Filtre
[]	Entrée de tableau
.	Attribut ou méthode d'un objet (ex : country.name)

Pour afficher la valeur NULL dans un opérateur ternaire, il faut la mettre entre apostrophes :

{{ (myVariable is not empty) ? '"' ~ myVariable.value ~ '"' : 'null' }}

Fonctions usuelles

• url() : affiche l'URL en chemin absolu. Les paramètres GET peuvent être ajoutés dans un tableau ensuite (ex : url(route_name, {'parametre1': param1}).
• path() : affiche l'URL en chemin relatif. Les paramètres GET peuvent être ajoutés dans un tableau ensuite (ex : path(route_name, {'parametre1': param1}).
• asset() : pointe vers le dossier des "assets" ("web" dans SF2, "public" dans SF4).
• controller() : exécute la méthode d'un contrôleur. Ex : {{ render_esi(controller('App\\Controller\\DefaultController:indexAction')) }}.
• constant() : importe une constante PHP.
• date() : convertit en date, ce qui permet leur comparaison. Ex : {% if date(x) > date(y) %}. NB : comme en PHP, "d/m/Y" correspond au format "jj/mm/aaaa".
• attribute() : accède à un attribut. C'est équivalent au "." mais la propriété peut être dynamique.

Filtres

Les filtres fournissent des traitements sur une expression, si on les place après elle séparés par des pipes. Par exemple :

• capitalize : équivaut au PHP ucfirst(), met une majuscule à la première lettre d'une chaine de caractères, et passe les autres en minuscules.
• upper : équivaut au PHP strtoupper(), met la chaine en lettres capitales. Exemple pour ne mettre la majuscule que sur la première lettre : {{ variable[:1]|upper ~ variable[1:] }}.
• first : affiche la première ligne d'un tableau, ou la première lettre d'une chaine.
• length : équivaut au PHP sizeof(), renvoie la taille de la variable (chaine ou tableau).
• format : équivaut au PHP printf().
• date : équivaut au PHP date() mais son format est du type DateInterval.
• replace : équivaut au PHP str_replace(). Ex : {{ 'Mon titre %tag%.'|replace({'%tag%': '1'}) }}.
• join : équivaut au PHP implode() : convertit un tableau en chaine avec un séparateur en paramètre.
• split : équivaut au PHP explode() : convertit une chaine en tableau avec un séparateur en paramètre.
• slice(début, fin) : équivaut au PHP array_slice() + substr() : découpe un tableau ou une chaine selon deux positions.
• trim : équivaut au PHP trim().
• raw : ne pas échapper les balises HTML.
• json_encode : transforme un tableau en chaine de caractères JSON.
• default : ce filtre lève les exceptions sur les variables non définies ou vides. Ex :

{{ variable1 |default(null) }}

Variables spéciales

• loop contient les informations de la boucle dans laquelle elle se trouve. Par exemple loop.index donne le nombre d'itérations déjà survenue (commence par 1 et pas par 0).
• Les variables globales commencent par des underscores, par exemple :
  • _route : partie de l'URL située après le domaine.
  • _self : nom de du fichier courant.
  • _charset : jeu de caractères de la page. Ex : UTF-8.
  • _context : variables injectées dans le template. Cela peut donc permettre d'y accéder en variables variables. Ex : {{ attribute(_context, 'constante'~variable) }}.
• Les variables d'environnement CGI, telles que {{ app.request.server.get('SERVER_NAME') }}

Pour obtenir la route d'une page : {{ path(app.request.attributes.get('_route'), app.request.attributes.get('_route_params')) }}

L'URL courante : {{ app.request.uri }}

La page d'accueil du site Web : url('homepage')

Gestion des espaces

spaceless

Un Twig bien formaté ne correspond pas forcément au rendu qu'il doit apporter. Pour supprimer les espaces du formatage dans ce rendu :

{% apply spaceless %}
    <b>
        Hello World!
    </b>
{% endspaceless %}

NB : en Twig < 2.7, c'était :

{% spaceless %}
    {% autoescape false %}
    <b>
        Hello World!
    </b>
{% endspaceless %}

Par ailleurs, il existe un filtre |spaceless.

-

De plus, on peut apposer le symboles "-" aux endroits où ignorer les espacements (dont retours chariot) du formatage :

    Hello {% ... -%}
    {%- ... %} World!

Cela fonctionne aussi entre {{- -}}.

Utilisation du traducteur

Configuration

Le module de traduction Symfony s'installe avec :

composer require translator

Quand une page peut apparaitre dans plusieurs langues, inutile d'injecter la locale dans le Twig depuis le contrôleur PHP, c'est une variable d'environnement que l'on peut récupérer avec :

{{ app.request.getLocale() }}

Le fichier YAML contenant les traductions dans cette langue sera automatiquement utilisé s'il est placé dans le dossier "translations" apparu lors de l'installation. En effet, il est identifié par le code langue ISO de son suffixe (ex : le Twig de la page d'accueil pourra être traduit dans homepage.fr.yml, homepage.en.yml, etc.).

Pour définir le préfixe des YAML auquel un Twig fera appel, on le définit sans suffixe en début de fichier Twig :

{% trans_default_domain 'homepage' %}

Par ailleurs, la commande PHP pour lister les traductions les traductions d'une langue est :

php bin/console debug:translation en --only-unused  // Pour les inutilisées
php bin/console debug:translation en --only-missing // Pour les manquantes

Filtre trans

Une fois la configuration effectuée, on peut apposer le filtre trans aux textes traduis dans le Twig.

{{ MessageInMyLanguage |trans }}

Parfois, il peut être utile de factoriser les traductions de plusieurs Twig dans un seul YAML. Pour piocher dans un YAML qui n'est pas celui par défaut, il suffit de le nommer en second paramètre du filtre trans :

 {{ 'punctuation_separator'|trans({}, 'common') }}

Si le YAML contient des balises HTML à interpréter, il faut apposer le filtre raw après trans.

Si une variable doit apparaitre dans une langue différente de celle de l'utilisateur, on le précisera dans le troisième paramètre du filtre trans :

{{ FrenchMessage |trans({}, 'common', 'fr') }}

Si le YAML doit contenir une variable, on la place entre pourcentages pour la remplacer en Twig avec le premier paramètre du filtre trans :

{{ variableMessage |trans({"%price%": formatPrice(myPrice)}) }}

Si la clé à traduire doit être variable, on ne peut pas réaliser la concaténation dans la même commande que la traduction : il faut décomposer en deux lignes :

{% set variableMessage = 'constante.' ~ variable %}
{{ variableMessage |trans }}

Opération trans

Il existe aussi une syntaxe alternative au filtre. Par exemple les deux paragraphes ci-dessous sont équivalents :

{{ 'punctuation_separator'|trans({}, 'common') }}

{% trans from 'common' %}
    punctuation_separator
{% endtrans %}

De plus, on peut injecter une variable avec "with". Voici deux équivalents :

{{ 'Bonjour %name% !' |trans({"%name%": name}) }}

{% trans with {'%name%': name}%}Bonjour %name% !{% endtrans %}

Méthodes PHP appelables en Twig

En PHP, on peut définir des fonctions invocables en Twig, sous forme de fonction ou de filtre selon la méthode parente surchargée. Exemple :

use Twig\Extension\AbstractExtension;
use Twig\TwigFilter;
use Twig\TwigFunction;

class TwigExtension extends AbstractExtension
{
    public function getFilters(): array
    {
        return [
            new TwigFilter('getPrice', [$this, 'getPrice']),
        ];
    }

    public function getFunctions(): array
    {
        return [
            new TwigFunction('getPrice', [$this, 'getPrice']),
        ];
    }

    public function getPrice($value): string
    {
        return number_format($value, 2, ',', ' ') . ' €';
    }
}

Héritages et inclusions

extends

Si une fichier appelé doit être inclus dans un tout, il doit en hériter avec le mot extends. Le cas typique est celui d'une "base.html.twig" qui contient l'en-tête et le pied de page HTML commun à toutes les pages d'un site. Ex :

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

Twig ne supporte pas l'héritage multiple.

Il est possible de surcharger totalement ou en partie les blocs du template parent. Exemple depuis le template qui hérite :

    {% block header %}
        Mon en-tête qui écrase le parent
    {% endblock %}

    {% block footer %}
        Mon pied de page qui complète le parent
        {{ parent() }}
    {% endblock %}

include

À contrario, si un fichier doit en inclure un autre (par exemple pour qu'un fragment de vue soit réutilisable dans plusieurs pages), on utilise le mot include. Ex :

    {% include("partials/footer.html.twig") %}

En lui injectant des paramètres :

    {% include("partials/footer.html.twig") with {'clé': 'valeur'} %}

On trouvait en Twig 1 la syntaxe {{ include() }} au lieu de {% include() %} en Twig 2.

render_esi

Inclus un Twig avec le cache Edge Side Includes.

embed

Enfin, embed combine les deux précédentes fonctions :

    {% embed "footer.html.twig" %}
        ...
    {% endembed %}

import

import récupère certaines fonctions d'un fichier en contenant plusieurs :

    {% from 'mes_macros.html' import format_price as price, format_date %}

Macros

Les macros sont des fonctions globales, appelables depuis un fichier Twig.

Exemple :

{% macro format_price(price, currency = '€') %}
    {% set locale = (app.request is null) ? 'fr_FR' : app.request.locale %}
    {% if locale == 'fr_FR' %}
        {{ price|number_format(2, ',', ' ') }} {{ currency }}
    {% else %}
        {{ price|number_format(2, '.', ' ') }}{{ currency }}
    {% endif %}
{% endmacro %}

Lors de l'appel, les paramètres nommés ne fonctionnent que si 100 % des paramètres appelés le sont.

Exemples

{% extends "base.html.twig" %}
{% block navigation %}
    <ul id="navigation">
    {% for item in navigation %}
        <li>
            <a href="{{ item.href }}">
                {% if item.level == 2 %}&nbsp;&nbsp;{% endif %}
                {{ item.caption|upper }}
            </a>
        </li>
    {% endfor %}
    </ul>
{% endblock navigation %}

Pour ne pas qu'un bloc hérité écrase son parent, mais l'incrémente plutôt, utiliser :

{{ parent() }}

Bonnes pratiques

Les noms des fichiers .twig doivent être rédigés en snake_case.

Doctrine

Installation

Doctrine est l'ORM par défaut de Symfony. Il utilise PDO. Son langage PHP traduit en SQL est appelé DQL, et utilise le principe de la chaîne de responsabilité.

Installation en SF4 :

composer require symfony/orm-pack
composer require symfony/maker-bundle --dev

Renseigner l'accès au SGBD dans le .env :

DATABASE_URL="mysql://mon_login:mon_mot_de_passe@127.0.0.1:3306/ma_base"

Ensuite la base de données doit être créée avec :

php bin/console doctrine:database:create

 symfony/orm-pack équivaut aux paquets suivants, qui peuvent bien sûr être installés séparément à la place :

• doctrine/doctrine-bundle
• doctrine/doctrine-migrations-bundle
• doctrine/orm
• symfony/proxy-manager-bridge

Commandes Doctrine

Exemples de commandes :

php bin/console dbal:run-sql "SELECT * FROM ma_table"
php bin/console doctrine:query:sql "$(< mon_fichier.sql)"
php bin/console doctrine:cache:clear-metadata
php bin/console doctrine:cache:clear-query 
php bin/console doctrine:cache:clear-result

Entity

Une entité est une classe PHP associée à une table de la base de données. Elle est composée d'un attribut par colonne, et de leurs getters et setters respectifs. Pour les générer à partir d'une base de données :

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

Cette commande est remplacée depuis 2019 par make:entity

Cette association est définie par des annotations Doctrine. Pour vérifier les annotations :

php bin/console doctrine:schema:validate

Exemple

Voici par exemple plusieurs types d'attributs :

#[ORM\Entity()]
#[ORM\Table(name: 'word')]
class Word
{

    #[ORM\Id]
    #[ORM\Column(name: 'id', type: 'integer', nullable: false, options=['unsigned'])]
    #[ORM\GeneratedValue(strategy: 'IDENTITY')]
    private $id;

    #[ORM\Column(name: 'spelling', type: 'string', nullable: false)]
    private $spelling;

    #[ORM\Column(name: 'pronunciation', type: 'string', nullable: true)]
    private $pronunciation;

    #[ORM\ManyToOne(targetEntity: 'Language')]
    #[ORM\JoinColumn(name: 'language_id', referencedColumnName: 'id', nullable: false)]
    private ?Language $language = null;

    #[ORM\OneToMany(targetEntity: Homophon::class, mappedBy: 'word', cascade: ['persist', 'remove'], orphanRemoval: true)]
    private ArrayCollection $homophons;

    public function __construct()
    {
        $this->homophons = new ArrayCollection();
    }

    public function setSpelling($p)
    {
        $this->spelling = $p;

        return $this;
    }

    public function getSpelling()
    {
        return $this->spelling;
    }

    public function setPronunciation($p)
    {
        $this->pronunciation = $p;

        return $this;
    }

    public function getPronunciation()
    {
        return $this->pronunciation;
    }

    public function setLanguage($l)
    {
        $this->language = $l;

        return $this;
    }

    public function getLanguage()
    {
        return $this->language;
    }

    public function addHomophons($homophon)
    {
        if (!$this->homophons->contains($homophon)) {
            $this->homophons->add($homophon);
            $homophon->setWord($this);
        }
        return $this;
    }
}

Exemple en PHP < 8

On utilise les annotations au lieu des attributs :

/**
* @ORM\Entity
* @ORM\Table(name="word")
*/
class Word
{
    /**
    * @ORM\Id
    * @ORM\Column(name="id", type="integer", nullable=false, options={"unsigned": true})
    * @ORM\GeneratedValue(strategy="IDENTITY")
    */
    private $id;

    /**
    * @ORM\Column(name="spelling", type="string", length=255, nullable=false)
    */
    private $spelling;

    /**
    * @ORM\Column(name="pronunciation", type="string", length=255, nullable=true)
    */
    private $pronunciation;

    /**
     * @var Language
     *
     * @ORM\ManyToOne(targetEntity="Language", inversedBy="words")
     * @ORM\JoinColumn(name="language_id", referencedColumnName="id")
     */
    protected $language;

    /**
     * @var ArrayCollection
     *
     * @ORM\OneToMany(targetEntity="Homophon", mappedBy="word", cascade={"persist", "remove"})
     */
    private $homophons;

    //...
}

 

On voit ici que la table "word" possède trois champs : "id" (clé primaire), "pronunciation" (chaine de caractère) et "language_id" (clé étrangère vers la table "language"). Doctrine stockera automatiquement l'id de la table "language" dans la troisième colonne quand on associera une entité "Language" à une "Word" avec $word->setLanguage($language).

Le quatrième attribut permet juste de récupérer les enregistrements de la table "homophon" ayant une clé étrangère pointant vers "word".

Par ailleurs, en relation "OneToMany", c'est toujours l'entité ciblée par le "Many" qui définit la relation car elle contient la clé étrangère. Elle contient donc l'attribut "inversedBy=", alors que celle ciblée par "One" contient "mappedBy=". Elle contient aussi une deuxième annotation @ORM\JoinColumn mentionnant la clé étrangère en base de données (et pas en PHP).

Dans les relations *toMany :

• il faut initialiser l'attribut dans le constructeur en ArrayCollection().
• on peut avoir une méthode ->set(ArrayCollection) mais le plus souvent on utilise ->add(un seul élément)
• cette méthode add() doit idéalement contenir le set() de l'entité cible vers la courante (pour ne pas avoir à l'ajouter après chaque appel).

NB : par défaut la longueur des types "string" est 255, on peut l'écraser ou la retirer avec length=0. Le type "text" par contre n'a pas de limite.

 l'annotation @ORM\Table(name="word") était facultative dans cet exemple, car le nom de la table peut être déduit du nom de l'entité.

L'annotation @ORM\Table peut servir à définir des clés composites :

 * @ORM\Table(uniqueConstraints={
 *  @ORM\UniqueConstraint(name="spelling-pronunciation", columns={"spelling", "pronunciation"})
 * })

ArrayCollection

Cet objet itérable peut être converti en tableau avec ->toArray().

Pour le trier :

• Dans une entité : @ORM\OrderBy({"sort_order" = "ASC"})
• Sinon, instancier un critère :

        $sort = new Criteria(null, ['slug' => Criteria::ASC]);
        $services = $maCollection->matching($sort);

GeneratedValue

L'annotation GeneratedValue peut valoir "AUTO", "SEQUENCE", "TABLE", "IDENTITY", "NONE", "UUID", "CUSTOM".

Dans le cas du CUSTOM, un setId() réaliser avant le persist() sera écrasé par la génération d'un nouvel ID. Ce nouvel ID peut être écrasé à son tour, mais si l'entité possède des liens vers d'autres, c'est l'ID custom qui est utilisé comme clé (on a alors une erreur Integrity constraint violation puisque la clé générée n'est pas retenue). Pour éviter cela (par exemple dans des tests automatiques), il faut désactiver la génération à la volée :

        $metadata = $this->em->getClassMetadata(get_class($entity));
        $metadata->setIdGeneratorType(ClassMetadata::GENERATOR_TYPE_NONE);
        $metadata->setIdGenerator(new AssignedGenerator());
        $entity->setId(static::TEST_ID);

Triggers

Les opérations en cascade sont définies sous deux formes d'annotations :

• cascade={"persist", "remove"} : au niveau ORM.
• onDelete="CASCADE" : au niveau base de données.

Concepts avancés

Pour utiliser une entité depuis une autre, alors qu'elles n'ont pas de liaison SQL, il existe l'interface ObjectManagerAware.

Les types des attributs peuvent être quelque peu différents du SGBD.

Dans le cas de jointure vers une entité d'un autre espace de nom (par exemple une table d'une autre base), il faut indiquer son namespace complet dans l'annotation Doctrine (car elle ne tient pas compte des "use").

L'autojointure est appelé self-referencing association mapping par Doctrine).

Héritage

Une entité peut hériter d'une classe si celle-ci contient l'annotation suivante :

/** @MappedSuperclass */
class MyEntityParent
...

EntityManager

L'EntityManager (em) est l'objet qui synchronise les entités avec la base de données. Une application doit en avoir un par base de données, définis dans doctrine.yaml.

Il possède trois méthodes pour cela :

• persist() : prépare un INSERT SQL (rattache une entité à un entity manager).
• remove() : prépare un DELETE SQL.
• flush() : exécute le code SQL préparé.

Il existe aussi les méthodes suivantes :

• merge() : fusionne une entité absent de l'em dedans.
• refresh() : rafraichit l'entité PHP à partir de la base de données. C'est utile par exemple pour tenir compte des résultats d'un trigger after insert sur le SGBD. Exemple si le trigger ajoute une date de création après le persist, à écraser par $createdDate :

        $entity = new MyEntity();
        $em->persist($entity);
        $em->flush($entity);
        // Trigger SGBD déclenché ici en parallèle
        $em->refresh($entity);
        $entity->setCreatedDate($createdDate);
        $em->flush($entity);

Repository

On appelle "repository" les classes PHP qui contiennent les requêtes pour la base de données. Elles héritent de Doctrine\ORM\EntityRepository. Chacune permet de récupérer une entité associée en base de données. Les repo doivent donc être nommés NomDeLEntitéRepository.

 d'un point de vue architectural, avant d'instancier une nouvelle entité, on utilise généralement le repository pour savoir si son enregistrement existe en base ou si on doit le créer. Dans ce deuxième cas, la bonne pratique en DDD est d'utiliser une Factory pour faire le new de l'entité, mais aussi pour les new de son agrégat si elle est le nœud racine. Par exemple une CarFactory fera un new Car() mais aussi créera et lui associera ses composants : new Motor()...

 il est possible de préciser le nom du repository d'une entité dans cette dernière :

@ORM\Entity(repositoryClass="App\Repository\WordRepository")

SQL

Depuis Doctrine

$rsm = new ResultSetMapping();
$this->_em->createNativeQuery('call my_stored_procedure', $rsm)->getResult();

Sans Doctrine

Pour exécuter du SQL natif dans Symfony sans Doctrine, il faut créer un service de connexion, par exemple qui appelle PDO en utilisant les identifiants du .env, puis l'injecter dans les repos (dans chaque constructeur ou par une classe mère commune) :

return $this->connection->fetchAll($sql);

Depuis un repository Doctrine, tout ceci est déjà fait et les deux techniques sont disponibles :

1. Par l'attribut entity manager (em, ou _em pour les anciennes versions) hérité de la classe mère (le "use" permettra ici d'appeler des constantes pour paramétrer le résultat) :

use Doctrine\DBAL\Connection;
...
$statement = $this->_em->getConnection()->executeQuery($sql);
$statement->fetchAll(\PDO::FETCH_KEY_PAIR);
$statement->closeCursor();
$this->_em->getConnection()->close();

return $statement;

2. En injectant le service de connexion dans le constructeur ('@database_connection') :

use Doctrine\DBAL\Connection;
...
return $this->dbalConnection->fetchAll($sql);

DQL

Constructeur

<?php

namespace App\Repository;

use App\Entity\Word;
use Doctrine\Bundle\DoctrineBundle\Repository\ServiceEntityRepository;
use Doctrine\Persistence\ManagerRegistry;

class WordRepository extends ServiceEntityRepository
{
    public function __construct(ManagerRegistry $registry)
    {
        parent::__construct($registry, Word::class);
    }
}

Méthodes magiques

Doctrine peut ensuite générer des requêtes SQL à partir du nom d'une méthode PHP appelée mais non écrite dans les repository (car ils en héritent). Ex :

• $repo->find($id) : cherche par la clé primaire définie dans l'entité.
• $repo->findAll() : récupère tous les enregistrements (sans clause WHERE).
• $repo->findById($id) : engendre automatiquement un SELECT * WHERE id = $id dans la table associée au repo.
• $repo->findBy(['lastname' => $lastname, 'firstname' => $firstname]) engendre automatiquement un SELECT * WHERE lastname = $lastname AND firstname = $firstname.
• $repo->findOneById($id) : engendre automatiquement un SELECT * WHERE id = $id LIMIT 1.
• $repo->findOneBy(['lastname' => $lastname, 'firstname' => $firstname]) : engendre automatiquement un SELECT * WHERE lastname = $lastname AND firstname = $firstname LIMIT 1.

Lors des tests unitaires PHPUnit, il est probable qu'une erreur survienne sur l'inexistence de méthode "findById" pour le mock du repository (du fait qu'elle est magique). Il vaut donc mieux utiliser findBy().

Par ailleurs, on peut compléter les requêtes avec des paramètres supplémentaires. Ex :

$repo->findBy(
    ['lastname' => $lastname], // where
    ['lastname' => 'ASC'],     // order by
    10,                        // limit
    0,                         // offset
);

Requête

Si les méthodes magiques ne suffisent pas, on peut créer sa propre méthode dans le repository de l'entité, avec des requêtes DQL plus complexes. Ex :

        $query = $em->createQuery("
            SELECT u.id, c.id
            FROM
                App\Entity\User u
                LEFT JOIN App\Entity\Company c WITH IDENTITY(u.company) = c.id               
            WHERE
                u.id < :maxId
            ORDER BY u.id DESC
        ")
        ->setParameter('maxId', 3);

        return $query->getResult();

setParameter échappe les apostrophes, pour y injecter un tableau PHP dans un IN SQL, on doit donc lui spécifier en troisième paramètre. Ex : query->setParameter('names', ['a', 'b', 'c'], \Doctrine\DBAL\Connection::PARAM_STR_ARRAY);

 pour convertir le DQL en SQL, il suffit d'appeler $query->getSQL(). S'il y a des paramètres DQL, il apparaissent alors comme des "?", mais on peut les compléter avec le résultat de $query->getParameters().

QueryBuilder

Doctrine permet aussi d'écrire des requêtes DQL en syntaxe de programmation objet. Les méthodes des repos font alors appel à createQueryBuilder() :

public function findAllWithCalculus(): ?array
{
    return $this->createQueryBuilder('mon_entité')
        ->where('id < 3')
        ->getQuery()
        ->getResult()
    ;
}

Pour éviter le SELECT * dans cet exemple, on peut y ajouter la méthode ->select().

Pour afficher la requête SQL générée par le DQL, remplacer "->getResult()" par "->getQuery()".

Jointures

Quand deux entités sont reliées entre elle, on peut utiliser une méthode pour définir leur jointure (inner, left ou right). Par exemple pour des utilisateurs avec leurs sociétés :

        return $this->createQueryBuilder('u')
            ->innerJoin('u.company', 'c')
            ->addSelect('c')
            ->where('u.isActive = true')
            ->andWhere('c.isClosed = false')
            ->orderBy('u.lastName', 'ASC')
            ->addOrderBy('c.firstName', 'ASC')
        ;

On peut même préciser les champs à sélectionner et la clé de jointure :

        return $this->createQueryBuilder('u')
            ->select(['u.lastName as name', 'u.company'])
            ->innerJoin('u.company', 'c', 'u.company = c.id')
            ->addSelect(['c.id', 'c.name'])
            ->where('u.isActive = true')
            ->andWhere('c.isClosed = false')
            ->orderBy('u.lastName', 'ASC')
            ->addOrderBy('c.firstName', 'ASC')
        ;

Quand deux entités ne sont pas reliées entre elles, on peut tout de même lancer une jointure en DQL :

use Doctrine\ORM\Query\Expr\Join;
...
    ->join('AcmeCategoryBundle:Category', 'c', Expr\Join::WITH, 'v.id = c.id')

Résultats

Doctrine renvoie des objets avec leurs méthodes (get pas set) avec getResult, ou un tableau avec getArrayResult, ou 2D avec getScalar.

• getResult() renvoie un objet ArrayCollection, pour rechercher dedans : ->contains().

Cache

Doctrine propose trois caches pour ses requêtes : celui de métadonnées, de requête et de résultats. Il faut d'abord définir les pools dans cache.yaml :

framework:
    cache:
        pools:
            doctrine.metadata_cache_pool:
                adapter: cache.system
            doctrine.query_cache_pool:
                adapter: cache.system
            doctrine.result_cache_pool:
                adapter: cache.app

Puis dans doctrine.yaml, les utiliser :

doctrine:
    orm:
        metadata_cache_driver:
            type: pool
            pool: doctrine.metadata_cache_pool
        query_cache_driver:
            type: pool
            pool: doctrine.query_cache_pool
        result_cache_driver:
            type: pool
            pool: doctrine.result_cache_pool

À partir de là le cache des métadonnées est utilisé partout.

Par contre pour ceux de requêtes et de résultats, il faut les définir pour chaque query builder de chaque repository :

$query
    ->useQueryCache($hasQueryCache)
    ->setQueryCacheLifetime($lifetime)
    ->enableResultCache($lifetime)
;

Dans cet exemple, on n'utilise pas cache.system pour le cache de résultats pour ne pas saturer le serveur qui héberge le code. cache.app pointe donc vers une autre machine, par exemple Redis, ce qui nécessite un appel réseau supplémentaire, et n'améliore donc pas forcément les performances selon la requête.

Expressions

Pour ajouter une expression en DQL, utilise $qb->expr(). Ex :

• $qb->expr()->count('u.id')
• $qb->expr()->between('u.id', 2, 10) (entre 2 et 10)
• $qb->expr()->gte('u.id', 2) (plus grand ou égal à 2)
• $qb->expr()->like('u.name', '%son')
• $qb->expr()->lower('u.name')
• $qb->expr()->substring('u.name', 0, 1)

Injection de dépendances

Les repository DQL deoivent ServiceEntityRepository :

namespace App\Repository;

use Doctrine\Bundle\DoctrineBundle\Repository\ServiceEntityRepository;

class WordRepository extends ServiceEntityRepository
{
    public function __construct(ManagerRegistry $registry)
    {
        parent::__construct($registry, Word::class);
    }
}

Mais parfois on souhaite injecter un service dans un repository. Pour ce faire il y a plusieurs solutions :

• Étendre une classe qui étend ServiceEntityRepository.
• Le redéfinir dans services.yaml.
• Utiliser un trait.

Transactions

Pour garantir d'intégrité d'une transaction :

            $connection = $this->entityManager->getConnection();
            $connection->beginTransaction();
            try {
                $this->persist($myEntity);
                $this->flush();
                $connection->commit();
            } catch (Exception $e) {
                $connection->rollBack();
                throw $e;
            }

Il existe aussi une syntaxe alternative :

            $em->transactional(function($em, $myEntity) {
                $em->persist($myEntity);
            });

Évènements

Pour ajouter des triggers sur la mise à jour d'une table, ajouter dans son entité :

#[Entity, HasLifecycleCallbacks]

Ou en PHP < 8 :

@ORM\HasLifecycleCallbacks()

Voici les évènements utilisables ensuite :

prePersist

S'exécute avant la persistance d'une entité (son INSERT en SQL).

postPersist

Après la persistance d'une entité.

preUpdate

Avant la mise à jour d'une entité (son UPDATE en SQL).

postUpdate

Après la mise à jour d'une entité.

preFlush

Avant la sauvegarde d'une entité.

onFlush

Pendant la sauvegarde d'une entité.

postFlush

Après la sauvegarde d'une entité.

preRemove

Avant la suppression d'une entité (son DELETE en SQL).

postRemove

Après la suppression d'une entité.

Précisions

• Dans cet évènement, les attributs en lazy loading de l'entité flushée s'ils sont appelés, sont issus de la base de données et donc correspondent aux données écrasées (et pas aux nouvelles flushées).
• Si on flush l'entité qui déclenche cet évènement il faut penser à un dispositif anti-boucle infinie (ex : variable d'instance).
• Dans le cas d'un new sur une entité, le persist ne suffit pas pour préparer sa sauvegarde. Il faut alors appeler $unitOfWork->computeChangeSet($classMetadata, $entity).

Migrations

Pour modifier la base de données avec une commande, par exemple pour ajouter une colonne à une table ou modifier une procédure stockée, il existe une bibliothèque qui s'installe comme suit :

composer require doctrine/doctrine-migrations-bundle

Création

Ensuite, on peut créer un squelette de "migration" :

php bin/console doctrine:migrations:generate

Cette classe comporte une méthode "up()" qui réalise la modification en SQL ou DQL, et une "down()" censée faire l'inverse à des fins de rollback. De plus, on ne peut pas lancer deux fois de suite le "up()" sans un "down()" entre les deux (une table nommée migration_versions enregistre leur succession).

Exemple SQL

final class Version20210719125146 extends AbstractMigration
{
    public function up(Schema $schema) : void
    {
        $this->connection->fetchAll('SHOW DATABASES;');

        $this->addSql(<<<SQL
          CREATE TABLE ma_table(ma_colonne VARCHAR(255) NOT NULL);
SQL);
    }

    public function down(Schema $schema) : void
    {
        $this->addSql('DROP TABLE ma_table');
    }
}

Exemple DQL

final class Version20210719125146 extends AbstractMigration
{
    public function up(Schema $schema) : void
    {
        $table = $schema->createTable('ma_table');
        $table->addColumn('ma_colonne', 'string');
    }

    public function down(Schema $schema) : void
    {
        $schema->dropTable('ma_table');
    }
}

Exemple PHP

final class Version20210719125146 extends AbstractMigration implements ContainerAwareInterface
{
    use ContainerAwareTrait;

    public function up(Schema $schema) : void
    {
        $em = $this->container->get('doctrine.orm.entity_manager');
        $monEntite = new MonEntite();
        $em->persist($monEntite);
        $em->flush();
    }
}

Cette technique est déconseillée car les entités peuvent évoluer indépendamment de la migration. Mais elle peut s'avérer utile pour stocker des données dépendantes de l'environnement.

$this->containergetParameter() ne fonctionne pas sur la valeur du paramètre quand elle doit être remplacée par une variable d'environnement. Par exemple $_SERVER['SUBAPI_URI'] renvoie la variable d'environnement et $this->containergetParameter('env(SUBAPI_URI)') sa valeur par défaut (définie dans services.yaml).

Exécution

La commande suivante exécute toutes les migrations qui n'ont pas encore été lancées dans une base :

php bin/console doctrine:migrations:migrate

Sinon, on peut les exécuter une par une selon le paramètre, avec la partie variable du nom du fichier de la classe (timestamp) :

php bin/console doctrine:migrations:execute --up 20170321095644
# ou si "migrations_paths" dans doctrine_migrations.yaml contient le namespace :
php bin/console doctrine:migrations:execute --up "App\Migrations\Version20170321095644"
# ou encore :
php bin/console doctrine:migrations:execute --up App\\Migrations\\Version20170321095644

Pour le rollback :

php bin/console doctrine:migrations:execute --down 20170321095644

Pour éviter que Doctrine pose des questions durant les migrations, ajouter --no-interaction (ou -n).

Pour voir le code SQL au lieu de l'exécuter : --write-sql.

Sur plusieurs bases de données

Pour exécuter sur plusieurs bases :

 php bin/console doctrine:migrations:migrate --em=em1 --configuration=src/DoctrineMigrations/Base1/migrations.yaml
 php bin/console doctrine:migrations:migrate --em=em2 --configuration=src/DoctrineMigrations/Base2/migrations.yaml

Avec des migrations.yaml de type :

name: 'Doctrine Migrations base 1'
migrations_namespace: 'App\DoctrineMigrations\Base1'
migrations_directory: 'src/DoctrineMigrations/Base1'
table_name: 'migration_versions'
# custom_template: 'src/DoctrineMigrations/migration.tpl'

Synchronisation

Vers le code

Vers les entités

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

Vers les migrations

Pour créer la migration permettant de parvenir à la base de données actuelle :

php bin/console doctrine:migrations:diff

Vers la base

À contrario, pour mettre à jour la BDD à partir des entités :

php bin/console doctrine:schema:update --force

Pour le prévoir dans une migration :

php bin/console doctrine:schema:update --dump-sql

Fixtures

Il existe plusieurs bibliothèques pour créer des fixtures, dont une de Doctrine :

composer require --dev orm-fixtures

Pour charger les fixtures du code dans la base :

php bin/console doctrine:fixtures:load -n

Types de champ

La liste des types de champ Doctrine se trouve dans Doctrine\DBAL\Types. Toutefois, il est possible d'en créer des nouveaux pour définir des comportements particuliers quand on lit ou écrit en base.

Par exemple on peut étendre JsonType pour surcharger le type JSON par défaut afin de lui faire faire json_encode($value, JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES) automatiquement.

Ou encore, pour y stocker du code de configuration désérialisé dans une colonne.

Critique

1. Il faut revenir en SQL si les performances sont limites (ex : un million de lignes avec jointures).
2. Si les valeurs d'une table jointe n'apparaissent pas tout le temps, vérifier que le lazy loading est contourné par au choix :
   1. Avant l'appel null, un ObjetJoint->get().
   2. Dans l'entité, un @ManyToOne(…, fetch="EAGER").
   3. Dans le repository, un $this->queryBuilder->addSelect().
3. Pas de HAVING MAX car il n'est pas connu lors de la construction dans la chaine de responsabilité
4. Pas de FULL OUTER JOIN ou RIGHT JOIN (que "leftJoin" et "innerJoin")
5. Attention aux $this->queryBuilder->setMaxResults() et $this->queryBuilder->setFirstResult() en cas de jointure, car elles ne conservent que le nombre d'enregistrements de la première table (à l'instar du LIMIT SQL). La solution consiste à ajouter un paginateur.
6. L'annotation @ORM/JOIN TABLE crée une table vide et ne permet pas d'y placer des fixtures lors de sa construction.
7. Pas de hints.
8. Bug des UNION ALL quand on joint deux entités non liées dans le repo.

API

Pour créer une interface de programmation (API) REST avec Symfony, il existe plusieurs bibliothèques :

• API Platform, tout-en-un qui utilise les annotations des entités pour créer les APIs (donc pas besoin de créer des contrôleurs ou autres). Par défaut il permet de sérialiser les flux en JSON (dont JSON-LD, JSON-HAL, JSON:API), XML (dont HTML), CSV, YAML, et même en GraphQL.
• Sinon il faut combiner plusieurs éléments : routeur, générateur de doc en ligne et sérialiseur.

API Platform

Installation

 composer require api

Utilisation

API Platform se configure par des annotations dans les entités.

Le GraphQL de la version 1.1 passe par le schéma REST, et ne bénéficie donc pas du gain de performances attendu sans overfetching.

Annotations

API\ApiResource()

Définit les noms et méthodes REST (get, post...) des routes de l'API.

MaxDepth()

Définit le niveau de sérialisation d'un élément lié. Par exemple, si un client a plusieurs contrats et que ses contrats ont plusieurs produits, un MaxDepth(1) sur l'attribut client->contrat fera que la liste des clients comprendra tous les contrats mais pas leurs produits.

Évènements

API Platform ajoute plus d'une dizaine d'évènements donc les priorités sont définies dans EventPriorities.

Par exemple, pour modifier un JSON POST envoyé, utiliser EventPriorities::PRE_DESERIALIZE.

L'évènement suivant POST_DESERIALIZE contient les objets instanciés à partir du JSON.

Features hors CRUD

Pour ajouter des fonctionnalités supplémentaires aux create/read/update/delete, il faut passer par des data providers ou des data persisters.

Triplet de bibliothèques

Installation

FOS REST

FOSRestBundle apporte des annotations pour créer des contrôleurs d'API. Installation :

composer require "friendsofsymfony/rest-bundle"

Puis dans config/packages/fos_rest.yaml :

fos_rest:
    view:
        view_response_listener:  true
    format_listener:
        rules:
            - { path: '^/',  prefer_extension: true, fallback_format: ~, priorities: [ 'html', '*/*'] }
            - { path: ^/api, prefer_extension: true, fallback_format: json, priorities: [ json ] }

Documentation

Toute API doit exposer sa documentation avec ses routes et leurs paramètres. NelmioApiDocBundle est un de générateur de documentation automatique à partir du code, qui permet en plus de tester en ligne. En effet, pour éviter de tester les API en copiant-collant leurs chemins dans une commande cURL ou dans des logiciels plus complets comme Postman, on peut installer une interface graphique ergonomique qui allie documentation et test en ligne :

    composer require "nelmio/api-doc-bundle"

Son URL se configure ensuite dans routes/nelmio_api_doc.yml :

app.swagger_ui:
    path: /api/doc
    methods: GET
    defaults: { _controller: nelmio_api_doc.controller.swagger_ui }

À ce stade l'URL /api/doc affiche juste un lien NelmioApiDocBundle. Mais si les contrôleurs d'API sont identifiés dans annotations.yaml (avec un préfixe "api"), on peut voir une liste automatique de toutes leurs routes.

Pour documenter /api/* sauf /api/doc, il faut préciser l'exception en regex dans packages/nelmio_api_doc.yaml :

nelmio_api_doc:
    areas:
        path_patterns:
            - ^/api/(?!/doc$)

Il faut vider le cache de Symfony à chaque modification de nelmio_api_doc.yaml.

Authentification

Pour tester depuis la documentation des routes nécessitant un token JWT, ajouter dans packages/nelmio_api_doc.yaml  :

nelmio_api_doc:
    documentation:
        securityDefinitions:
            Bearer:
                type: apiKey
                description: 'Value: Bearer {jwt}'
                name: Authorization
                in: header
        security:
            - Bearer: []

Il devient alors possible de renseigner le token avant de tester.

Sérialiseur

Enfin pour la sérialisation, on distingue plusieurs solutions :

• symfony/serializer, qui donne des contrôleurs extends AbstractFOSRestController et des méthodes aux annotations @Rest\Post().
• jms/serializer-bundle, avec des contrôleurs extends RestController et des méthodes aux annotations @ApiDoc().
• Le service fos_rest.service.serializer.

symfony/serializer

    composer require "symfony/serializer"

jms/serializer-bundle

    composer require "jms/serializer-bundle"

Utilisation

Maintenant /api/doc affiche les méthodes des différents contrôleurs API. Voici un exemple :

<?php

namespace App\Controller;

use FOS\RestBundle\Controller\AbstractFOSRestController;
use FOS\RestBundle\View\View;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\Routing\Annotation\Route;

class APIController extends AbstractFOSRestController
{
    #[Route('/api/test', methods: ['GET'])]
    public function testAction(Request $request): View
    {
        return View::create('ok');
    }
}

Dans PHP < 8

...
    /**
     * @Route("/api/test", methods={"GET"})
     */
    public function testAction(Request $request): View
...
}

 

Maintenant dans /api/doc, cliquer sur /api/test, puis "Ty it out" pour exécuter la méthode de test.

Sécurité

Une API étant stateless, l'authentification est assurée à chaque requête, par l'envoi par le client d'un token JSON Web Token (JWT) dans l'en-tête HTTP (clé Authorization). Côté serveur, on transforme ensuite le JWT reçu en objet utilisateur pour accéder à l'identité du client au sein du code. Ceci est fait en configurant security.yaml, pour qu'un évènement firewall appelle automatiquement un guard authenticator :

composer require "symfony/security-bundle"

security:
    firewalls:
        main:
            guard:
                authenticators:
                    - App\Security\TokenAuthenticator

Test

Pour tester en shell :

TOKEN=123
curl -H 'Accept: application/json' -H "Authorization: Bearer ${TOKEN}" http://localhost

Références

GFDL

Vous avez la permission de copier, distribuer et/ou modifier ce document selon les termes de la licence de documentation libre GNU, version 1.2 ou plus récente publiée par la Free Software Foundation ; sans sections inaltérables, sans texte de première page de couverture et sans texte de dernière page de couverture.