Nous allons voir comment commencer avec Symfony avec un exemple pratique. nous faisons une application web classique c’est à dire pas de framework javascript pour l’instant, mais une application web avec formulaire, persistence de données dans la base de données avec un modèle de données très simple.
Nous n’allons pas voir l’authentification pour l’instant, on pourra donc aller sur toutes les pages web créées.
Contenu
Avec Composer bootstrappez une application Symfony 4 en ligne de commande
Vous devez connaitre la ligne de commande pour travailler efficacement avec Symfony. Ainsi c’est avec la ligne de commande qu’on va commencer à travailler ! Tout d’abord vous devez avoir installé Composer, sans ceci les chargement de classe PHP seraient difficiles.
composer create-project symfony/skeleton monsite
Cette commande va installer tous les fichiers et ainsi créer une structure de répertoires
monsite/ ├─ bin/ │ └─ console ├─ config/ └─ public/ │ └─ index.php ├─ src/ │ └─ Kernel.php ├─ var/ │ ├─ cache/ │ └─ log/ └─ vendor/
Cette structure de répertoires est par défaut et à l’avantage d’être claire et simple, cependant vous pouvez modifier cette structure, ce que je ne vous recommande pas avant d’avoir maitrisé Symfony 4.
Un mot sur l’organisation de code, à l’époque de Symfony 2, les différentes parties d’un logiciel étaient organisées en bundle (le terme de Symfony pour plugin), or le problème c’est qu’on s’attend à ce que ces bundles soient réutilisables, c’est le propre d’un plugin). Du coup pas mal d’applications sont organisées en bundle pas vraiment réutilisables, avec Symfony 4 on s’organise différemment, il n’y a plus de bundle, sauf pour les vrais bundles réutilisables comme le FOSUserBundle.
Tous les codes métiers de votre application sont dans le répertoire src/, le répertoire public contient un fichier index.php qui ne fait que recevoir la requête du browser en premier, vous y mettez aussi les code css et js. Le répertoire config contient les nombreux fichiers au format YAML, qui paramètre votre application. Il y a les fichiers pour le core, mais aussi pour les différents bundles comme FOSUserBundle. On y trouve principalement :
└─ config/ ├─ packages/ │ └─ security.yaml ├─ routes.yaml ├─ services.yaml └─ routes.yaml
Il y a le répertoire très important vendor/, qui contient toutes les dépendances de votre application. Symfony est lui même organisé en bundle, donc le core de Symfony est dans le dossier vendor/, les fichiers situés dans ce répertoire sont installés par composer, regardez votre fichier composer.json, vous verrez le parallèle avec l’arborescence de répertoire.
Avant Symfony 4, on installait un bundle ou une librairie PHP avec typiquement une commande :
composer require doctrine/orm composer require doctrine/doctrine-bundle composer require doctrine/doctrine-migrations-bundle # Avec Flex composer require symfony/orm-pack
Avec Flex, on ne s’occupe pas vraiment de savoir quels bundles installer, on tape une commande au lieu de trois, dans le jargon on appelle ça une recette, voir ci-dessus. On veut installer un système d’ORM, en l’occurence Doctrine dans la communauté Symfony (mais normalement vous pouvez installer un autre ORM si vous voulez). Au lieu de s’assurer quels bundle installer, on a une recette et en une seule ligne, les trois bundles sont installés.
En réalité, le système va chercher un fichier composer.json qui contient les informations pour installer les 3 bundles. Et plus généralement, plutôt que de faire un composer require, on peut mettre la dépendance dans le fichier composer.json et faire un composer update.
Passons à la configuration de l’application Symfony 4
Il y a beaucoup d’endroits où l’on fait la configuration d’une application Symfony 4, mais il y a un fichier fondamental qui est .env, où sont faits les paramétrages de la base de données, et des emails. Mais c’est ici aussi que vous décidez de vous mettre en environnement de développement, test ou production. En fait ce fichier concerne les environnements, autrement dit des machines, c’est pour ça qu’on n’est pas dans les fichier YAML, qui sont relatifs à l’application même.
Les fichiers .env, .env.local
On peut penser que ce fichier ne doit pas être versionné, car il est spécifique à chaque environnement, en fait il faut savoir qu’il y a eu un changement en 2018 dans la façon de gérer les environnement, voici le lien pour plus de clarté (lisez cette page qui est importante si vous devez migrer des anciennes versions de Symfony), en gros le fichier .env peut être versionné, donc quid des informations sensibles comme les mots de passe? La documentation mentionne un fichier .env.local qui override .env, donc ce dernier est spécifique à chaque environnement et il ne doit pas être versionné, et peut donc contenir des informations sensibles.
Les fichiers de configuration YAML
J’avais dit que les fichiers YAML sont uniquement applicatifs, cependant il peut arriver que des valeurs peuvent dépendre des environnement, dans ce cas, si par exemple en développement et en production, des valeur changeaient, il est possible de créer des fichiers YAML spécifiques, ainsi Symfony 4 supporte les fichiers services_dev.yaml et services_prod.yaml pour distinguer.
Attention à ne pas trop surcharger les pages avec des paramètres qui n’ont pas lieu d’être déclarés dans un fichier YAML, la documentation officielle mentionne l’exemple de la pagination d’une page avec un nombre de billets par page, ce genre de valeur est mieux défini dans une constante PHP dans une entité.
Règles de nommage des paramètres
voici quelques règles à suivre : soyez spécifique dans les noms, il est d’usage de commencer par app suivi d’un point puis le nom du paramètre, trait d’union autorisé.
Conclusion
A ce stade vous devriez avoir une application minimaliste, sans accès à la base de données, nous n’avons pas encore fait marcher l’application ! Pour ce faire il faut créer et configurer un virtual host avec des règles de réécriture qui vont bien, pourqu’on puisse avoir une page d’accueil qui ressemble à ça :
Maintenant il faut essayer de faire une page web à la Symfony, c’est à dire avec une route, un controller, un formulaire, un template Twig, mais pas encre de persistence en base de données.