• 30 hours
  • Medium

Free online content available in this course.

course.header.alt.is_video

course.header.alt.is_certifying

Got it!

Last updated on 5/13/19

Vous avez dit Symfony ?

Log in or subscribe for free to enjoy all this course has to offer!

Dans ce chapitre, nous allons voir comment est organisé Symfony à l'intérieur. Nous n'entrerons pas dans les détails, c'est trop tôt, le but est juste d'avoir une vision globale du processus d'exécution d'une page sous Symfony. Ainsi, vous pourrez comprendre ce que vous faites. C'est mieux, non ? :)

L'architecture des fichiers

On vient d'extraire beaucoup de fichiers, mais sans savoir encore à quoi ils servent. C'est le moment d'éclaircir tout cela !

Liste des répertoires

Ouvrez donc le répertoire dans lequel vous avez extrait les fichiers. Vous pouvez voir qu'il n'y a pas beaucoup de fichiers ici, seulement des répertoires. En effet, tout est bien rangé dans chaque répertoire, il nous faut donc comprendre à quoi ils servent. En voici la liste :

  • bin

  • config

  • public

  • src

  • var

  • vendor

 Le répertoire /bin

Ce répertoire contient tous les exécutable dont nous allons nous servir pendant le développement. Par exécutable, j'entends des commandes PHP, comme on l'a fait avec Composer pour installer Symfony au chapitre précédent. Je vous le montrerai pas à pas.

Le répertoire  /config

Ce répertoire contient toute la configuration de votre site. C'est ici que nous configurerons Symfony lui-même, mais aussi les plugins (ou bundles) que nous installerons par la suite. La configuration des différentes parties est éclatée dans différents répertoires et fichiers à l'intérieur de  /config .

Le répertoire  /public

Ce répertoire contient tous les fichiers destinés à vos visiteurs : images, fichiers CSS et JavaScript, etc. Il contient également le contrôleur frontal (  index.php ), dont nous parlerons juste après.

En fait, c'est le seul répertoire qui devrait être accessible à vos visiteurs, d'où son nom : « public ». Les autres répertoires ne sont pas censés être accessibles (ce sont vos fichiers de code source, ils vous regardent vous, pas vos visiteurs). On utilisera donc toujours des URL du type  http://localhost/mooc-symfony4/public/…  au lieu de simplement  http://localhost/mooc-symfony4/….

Le répertoire/src

Voici enfin le répertoire dans lequel on mettra le code source ! C'est ici que l'on passera le plus clair de notre temps. Vous pouvez voir que ce répertoire n'est pas vide : il contient en effet le noyau (kernel) que nous aborderons plus tard dans ce cours.

Le répertoire  /template

Ce répertoire n'existe pas encore :) Mais il contiendra tous les templates de notre application. Si vous connaissez déjà le modèle MVC, cela correspond aux vues. Sinon, pas de panique nous l'évoquons plus bas dans ce chapitre. C'est principalement ici que sera le HTML que nous écrirons.

Le répertoire /var

Ce répertoire contient tout ce que Symfony va écrire durant son exécution : les logs, le cache, et d'autres fichiers nécessaires à son bon fonctionnement. Nous n'écrirons jamais dedans nous même.

Le répertoire/vendor

Ce répertoire contient toutes les bibliothèques externes à notre application. Dans ces bibliothèques externes, j'inclus Symfony ! Vous pouvez parcourir ce répertoire ; pour l'instant il n'y a quasiment que Symfony. Nous ajouterons des nouvelles bibliothèques suivant nos besoins, au fur et à mesure du cours.

Et une bibliothèque, c'est quoi exactement ?

Une bibliothèque est une sorte de boîte noire qui remplit une fonction bien précise, et dont on peut se servir dans notre code. Par exemple, la bibliothèque SwiftMailer permet d'envoyer des e-mails. On ne sait pas comment elle fonctionne (principe de la boîte noire), mais on sait comment s'en servir : on pourra donc envoyer des e-mails très facilement, juste en apprenant rapidement à utiliser la bibliothèque. C'est une des bibliothèques que nous allons installer plus tard dans le cours.

À retenir

Retenez donc que nous passerons la plupart de notre temps dans le répertoire/src, à travailler sur nos bundles. On touchera également pas mal au répertoire/config pour configurer notre application. Et lorsque nous installerons des bibliothèques, Composer le fera pour nous dans le répertoire/vendor.

Le contrôleur frontal

Définition

Le contrôleur frontal (front controller, en anglais) est le point d'entrée de votre application. C'est le fichier par lequel passent toutes vos pages. Vous devez surement connaître le principe d'index.php et des pseudo-frames (avec des URL du typeindex.php?page=blog) ; eh bien, cetindex.php est un contrôleur frontal. Dans Symfony, le contrôleur frontal se situe dans le répertoire/public, il s'appelle également  index.php .

Concrètement, que « contrôle » le contrôleur frontal ?

Très bonne question. Pour cela, rien de tel que… d'ouvrir le fichier  index.php . Ouvrez-le et vous constaterez qu'il ne fait pas grand-chose. En effet, le but du contrôleur frontal n'est pas de faire quelque chose, mais d'être un point d'entrée de notre application. Il se limite donc (en gros) à appeler le noyau (kernel) de Symfony en disant « On vient de recevoir une requête, transforme-la en réponse s'il-te-plaît. » (lignes 35 à 39).

Ici, voyez le contrôleur frontal comme un fichier à nous (il est dans notre répertoire  /public ), et le Kernel comme un composant Symfony, une boîte noire (il est dans le répertoire  /vendor ). Vous voyez comment on a utilisé notre premier composant Symfony : on a délégué la gestion de la requête au Kernel. Bien sûr, ce Kernel aura besoin de nous pour savoir quel code exécuter, mais il nous simplifiera la vie !

Les environnements

Le Kernel est créé avec deux arguments :  $env  et  $debug . A quoi cela correspond ?

Bien vu ! Attardons-nous sur le premier argument,  $env , pour environnement.

L'objectif de Symfony est de nous faciliter le développement. C'est pourquoi il propose deux « modes » d'accès à notre application : l'un pour nos visiteurs, et l'autre pour nous, lorsque nous développons. Ces deux modes définissent en fait deux environnements de travail.

Deux environnements de travail

L'objectif est de répondre au mieux suivant la personne qui visite le site :

  • Un développeur a besoin d'informations sur la page afin de l'aider à développer. En cas d'erreur, il veut tous les détails pour pouvoir déboguer facilement. Il n'a pas besoin de rapidité.

  • Un visiteur normal n'a pas besoin d'informations particulières sur la page. En cas d'erreur, l'origine de celle-ci ne l'intéresse pas du tout, il veut juste retourner d'où il vient. Par contre, il veut que le site soit le plus rapide possible à charger.

Vous voyez la différence ? À chacun ses besoins, et Symfony compte bien tous les remplir. C'est pourquoi il offre plusieurs environnements de travail :

  • L'environnement de développement, appelé « dev », c'est celui qui est configuré par défaut. C'est l'environnement que l'on utilisera toujours pour développer.

  • L'environnement de production, appelé « prod ».

Chaque environnement correspond à où est exécutée l'application (notre site web). Si l'application est exécutée sur notre propre PC de développeur, alors le mot de passe de la base de données sera différent de si l'application était exécutée sur un serveur dans un datacenter par exemple.

Mais comment faire pour passer de l'un à l'autre ?

Pour changer d'environnement, ainsi que toutes les variables qui en dépendent (mot de passe de la base de données, etc.), rendez-vous dans le fichier  .env  à la racine du projet. C'est un fichier de configuration dans lequel on va définir ces valeurs qui dépendent de l'environnement.

Essayez de changer la valeur de  APP_ENV  à  prod . Puis retournez sur la page http://localhost/mooc-symfony4/public/index.php/ et vous obtiendrez... une erreur ! :p

En prod, c'est moins joli !
En prod, c'est moins joli !

La page de bienvenue que nous avons vu plus tôt n'est en fait disponible que dans l'environnement de développement. C'est bien évidemment une page que l'on ne veut pas afficher à nos futurs visiteurs ! On a donc ici une erreur 500, toute blanche parce que mon serveur web (Apache) n'est pas configuré pour afficher autre chose.

Pour voir le comportement du mode « dev » en cas d'erreur, essayez aussi d'aller sur une page qui n'existe pas. Vous avez vu ce que donne une page introuvable en mode « prod », mais rechangez (définitivement) le paramètre  APP_DEV  à  dev  et allez sur /index.php/pagequinexistepas. La différence est claire : le mode « prod » nous dit juste « page introuvable » alors que le mode « dev » nous donne plein d'informations sur l'origine de l'erreur, indispensables pour la corriger.

Affichage d'une page 404 en mode « dev »
Affichage d'une page 404 en mode « dev »

C'est pourquoi, dans la suite du cours, nous utiliserons toujours le mode « dev ». Bien sûr, lorsque votre site sera opérationnel et que des internautes pourront le visiter, il faudra leur faire utiliser le mode « prod » sur votre serveur de production. Mais nous n'en sommes pas encore là.

L'architecture conceptuelle

On vient de voir comment sont organisés les fichiers de Symfony. Maintenant, il s'agit de comprendre comment s'organise l'exécution du code au sein de Symfony.

Architecture MVC

Vous avez certainement déjà entendu parler de ce concept. Sachez que Symfony respecte bien entendu cette architecture MVC. Je ne vais pas entrer dans ses détails, car il y a déjà un super cours sur le site OpenClassrooms intitulé Adoptez un style de programmation claire avec le modèle MVC (par Vincent1870), mais en voici les grandes lignes.

MVC signifie « Modèle / Vue / Contrôleur ». C'est un découpage très répandu pour développer les sites Internet, car il sépare les couches selon leur logique propre :

  • Le Contrôleur (ou Controller) : son rôle est de générer la réponse à la requête HTTP demandée par notre visiteur. Il est la couche qui se charge d'analyser et de traiter la requête de l'utilisateur. Le contrôleur contient la logique de notre site Internet et va se contenter « d'utiliser » les autres composants : les modèles et les vues. Concrètement, un contrôleur va récupérer, par exemple, les informations sur l'utilisateur courant, vérifier qu'il a le droit de modifier tel article, récupérer cet article et demander la page du formulaire d'édition de l'article. C'est tout bête, avec quelquesif(), on s'en sort très bien.

  • Le Modèle (ou Model) : son rôle est de gérer vos données et votre contenu. Reprenons l'exemple de l'article. Lorsque je dis « le contrôleur récupère l'article », il va en fait faire appel au modèleArticleet lui dire : « donne-moi l'article portant l'id 5 ». C'est le modèle qui sait comment récupérer cet article, généralement via une requête au serveur SQL, mais ce pourrait être depuis un fichier texte ou ce que vous voulez. Au final, il permet au contrôleur de manipuler les articles, mais sans savoir comment les articles sont stockés, gérés, etc. C'est une couche d'abstraction.

  • La Vue (ou View) : son rôle est d'afficher les pages. Reprenons encore l'exemple de l'article. Ce n'est pas le contrôleur qui affiche le formulaire, il ne fait qu'appeler la bonne vue. Si nous avons une vueFormulaire, les balises HTML du formulaire d'édition de l'article y seront et au final le contrôleur ne fera qu'afficher cette vue sans savoir vraiment ce qu'il y a dedans. En pratique, c'est le designer d'un projet qui travaille sur les vues. Séparer vues et contrôleurs permet aux designers et développeurs PHP de travailler ensemble sans se marcher dessus.

Au final, si vous avez bien compris, le contrôleur ne contient que du code très simple, car il se contente d'utiliser des modèles et des vues en leur attribuant des tâches précises. Il agit un peu comme un chef d'orchestre, qui n'agite qu'une baguette alors que ses musiciens jouent des instruments complexes.

Parcours d'une requête dans Symfony

Afin de bien visualiser tous les acteurs que nous avons vus jusqu'à présent, je vous propose un schéma du parcours complet d'une requête dans Symfony :

Parcours complet d'une requête dans Symfony2
Parcours complet d'une requête dans Symfony

En le parcourant avec des mots, voici ce que cela donne :

  1. Le visiteur demande la page/platform ;

  2. Le contrôleur frontal reçoit la requête, charge le Kernel et la lui transmet ;

  3. Le Kernel demande au Routeur quel contrôleur exécuter pour l'URL/platform. Ce Routeur est un composant Symfony qui fait la correspondance entre URL et contrôleurs, nous l'étudierons bien sûr dans un prochain chapitre. Le Routeur fait donc son travail, et dit au Kernel qu'il faut exécuter le contrôleurOCPlatform:Advert ;

  4. Le Kernel exécute donc ce contrôleur. Le contrôleur demande au modèleAnnonce la liste des annonces, puis la donne à la vueListeAnnonces pour qu'elle construise la page HTML et la lui retourne. Une fois cela fini, le contrôleur envoie au visiteur la page HTML complète.

J'ai mis des couleurs pour distinguer les points où l'on intervient. En vert, les contrôleur, modèle et vue, c'est ce qu'on devra développer nous-mêmes. En orange, le Kernel et le Routeur, c'est ce qu'on devra configurer. On ne touchera pas au contrôleur frontal, en gris.

Maintenant, il ne nous reste plus qu'à voir comment organiser concrètement notre code et sa configuration.

En résumé

  • Symfony est organisé en septs répertoires :binconfig , publicsrc ,templates , var etvendor.

  • Les répertoires dans lequel on passera le plus de temps sontsrc et  templates . Ils contiennent le code source et le HTML de notre site.

  • Il existe deux environnements de travail :

    • L'environnement « prod » est destiné à vos visiteurs : il est rapide à exécuter, et ne divulgue pas les messages d'erreur.

    • L'environnement « dev » est destiné au développeur, c'est-à-dire vous : il est plus lent, mais offre plein d'informations utiles au développement.

  • Symfony utilise l'architecture MVC pour bien organiser les différentes parties du code source.

Example of certificate of achievement
Example of certificate of achievement