Passez en environnement de développement
Le Profileur Web est une application délivrée avec le framework Symfony uniquement disponible en environnement de développement... mais qu'est-ce qu'un environnement ? :o
Environnement et gestionnaire d'erreurs
Rappelez-vous lorsque nous avions vu un exemple de contrôleur frontal du framework Symfony :
<?php
// public/index.php
use Symfony\Component\HttpFoundation\Request;
require __DIR__.'/../vendor/autoload.php';
$environment = 'prod';
$debugEnabled = false;
$kernel = new AppKernel($environment, $debugEnabled);
$request = Request::createFromGlobals();
$response = $kernel->handle($request);
$response->send();
$kernel->terminate($request, $response);Volontairement, nous n'avions pas abordé l'utilité des variables $environnement et $debugEnabled.
L'environnement correspond à la configuration sélectionnée lors de l'exécution de l'application, et par défaut, Symfony en fournit trois : "prod", "dev" et "test", et vous pouvez en créer autant que vous le souhaitez.
Ce qu'il est important de retenir ici, c'est qu'une configuration spécifique de l'application sera chargée en fonction de l'environnement sélectionné.
Regardons ensemble la configuration d'une application de démonstration, habituellement localisée dans le dossier config :
. ├── packages/ │ ├── dev/ │ ├── prod/ │ ├── test/ │ ├── framework_extra.yaml │ ├── framework.yaml │ ├── doctrine_migrations.yaml │ ├── routing.yaml │ ├── security.yaml │ ├── swiftmailer.yaml │ ├── doctrine.yaml │ ├── translation.yaml │ ├── twig_extensions.yaml │ └── twig.yaml ├── services_test.yaml └── services.yaml
Pour comprendre la puissance et la flexibilité du système, voici comment sont chargés les fichiers de configuration lors de l'exécution de l'application :
D'abord, tous les fichiers disponibles à la racine du dossier packages sont chargés.
Ensuite, tous les fichiers disponibles dans le dossier packages/{environnement} sont chargés.
Troisièmement, le fichier services (l'extension importe peu) sera chargé.
Et pour conclure, le fichier services_{environnement} (s'il existe) sera chargé.
Sachant que, si une configuration est déjà décrite dans un fichier précédent, elle sera surchargée.
D'accord, j'ai compris : mais comment sélectionne-t-on un environnement?
Eh bien, c'est très simple ! À la racine de votre projet, vous retrouvez un fichier appelé .env qui contient les variables d'environnement qui seront disponibles dans votre application. Les deux variables qui nous intéressent ici se nomment APP_ENV et APP_DEBUG :
# .env
###> symfony/framework-bundle ###
APP_ENV=prod # ou "dev" ou "test"
APP_DEBUG=0 # ou 1 pour désactiver
# ...
###< symfony/framework-bundle ###
Bingo ! En changeant uniquement le contenu de ce fichier, vous passez votre application en environnement de développement ou de production.
Mode de débogage
Le mode de débogage n'a pas de rapport direct avec l'environnement sélectionné dans l'application de Symfony, même s'il sera généralement activé en environnement de test et de développement, et désactivé en environnement de production.
Ce mode de débogage permet d'activer un puissant gestionnaire d'erreurs et de désactiver la mise en cache des éléments de configuration et de gabarit : c'est généralement ce que l'on souhaite lorsque l'on développe ou teste son application.
En environnement de production, les erreurs ne seront pas affichées et il sera possible de configurer des pages d'erreurs spécifiques.
Découvrez le Profileur Web
Le Profileur Web est une application d'aide au développement activée en environnement de développement, constituée de deux éléments principaux : une barre de débogage et une application web de profilage.
La barre de débogage
En environnement de développement, une barre de débogage est automatiquement injectée dans la page HTML retournée à l'utilisateur :
Cette barre apporte de nombreuses informations récoltées lors de l'exécution de votre application :
à gauche, le code HTTP de la réponse : si tout s'est bien passé, ce bloc sera en vert, sinon en rouge ;
le nom de la route qui a été trouvée et exécutée par l'application : "homepage" ;
des informations de performance : la page s'est exécutée en 90 millisecondes, a consommé 2 mégabytes de mémoire vive et occasionné 61 appels au cache applicatif ;
des informations sur l'internationalisation : 16 clés de traduction ont été affichées ;
des informations sur la base de données : 3 requêtes SQL ont été exécutées ;
et la version du framework utilisée !
L'ensemble des blocs affichent un complément d'information au survol de la souris, et cliquer sur la barre de débogage permet d'accéder au Profileur Web.
Le Profileur Web
Le Profileur Web est une application permettant de récolter, de traiter et d'afficher des informations lors de l'exécution d'une application Symfony. Pour chaque profil établi, un token unique est créé et permet d'accéder aux informations du profil généré :
Vous aurez l'occasion de parcourir les différents onglets de cette application lorsque vous développerez vos applications. Voici quelques points importants à retenir :
l'onglet "Performances" qui est présenté en détail dans le cours sur la performance PHP vous donne de nombreuses informations sur l'exécution de votre application ;
l'onglet "Configuration" contient un lien vers la configuration de PHP, en plus des modules installés (on dit "bundle") ;
l'onglet "Routing" est utile pour comprendre pourquoi la page affichée n'est peut-être pas celle que vous attendiez :o ;
enfin, dans les en-têtes de la réponse HTTP de votre page, vous retrouverez le token du profil généré lors de l'exécution de la page : très utile si vous développez une application REST.
... et c'est d'ailleurs sur ce type d'application que vous allez travailler dans l'exercice qui suit. :ange:
Déboguez une API REST avec le serveur de développement
Il reste un dernier sujet à traiter : comment faire lorsque l'application à développer n'est pas une application qui génère du HTML, comme une application en ligne de commande ou encore une application REST ?
Pour une application REST, on peut toujours retrouver le token, mais si l'on doit générer un profil à chaque fois que l'on essaye de corriger l'application, cela risque d'être long et un peu pénible...
Symfony embarque un serveur de débogage qui affichera le résultat en console de tout élément qui aura été "dumpé" dans l'application (la fonction dump() étant un var_dump() amélioré fourni avec le framework Symfony).
En résumé
Une application Symfony possède plusieurs environnements qui correspondent à des configurations différentes en fonction du contexte : en production, en développement ou encore en environnement de test. Sur votre machine, vous éditerez un fichier appelé .env dans lequel vous pourrez choisir quel environnement charger et d'activer le gestionnaire d'erreurs.
Elle dispose d'un gestionnaire d'erreurs qui permet d'afficher de nombreuses informations supplémentaires en cas d'erreurs dans votre application.
Couplé à la barre de débogage et au profileur web, vous disposez d'un outillage extraordinaire pour parvenir à trouver la source d'une erreur et la corriger.
En plus de la fonction dump() disponible depuis les toutes premières versions de Symfony, vous pouvez activer un serveur de débogage, bien utile quand l'accès au profileur web est difficile ou impossible (comme dans le cas d'une application en ligne de commandes).
Maintenant que vous êtes équipé pour corriger tout type d'erreur, il est temps de voir comment dynamiser vos vues à l'aide de Twig et l'accès à une base de données à l'aide de Doctrine ORM.
On se retrouve dans la prochaine partie !
