Une première application

La structure de Symfony

Toute l’application sera développée sous le dossier src. C’est ici, principalement que nous coderons toute notre application.

Le framework Symfony utilise une structure bien connue : la structure MVC. MVC signifie : Modèle, Vue, Contrôleur

Détaillons un peu ces trois éléments de structure.

Les contrôleurs

Les contrôleurs seront tous créés dans le sous-dossier : src/Controller. Pour l’instant, ce dossier est vide.

Créons par exemple un contrôleur TestController, pour tester notre application. Sur la fenêtre du terminal, tapez la commande :

php bin/console make:controller TestController 

Il se peut que vous obteniez le message d’erreur suivant :

Dans ce cas, votre installation n’a pas intégré une librairie qui s’appelle Symfony MakerBundle. Il faut bien sûr utiliser Composer pour l’installer :

composer require symfony/maker-bundle --dev 

 APP_ENV=dev 

php bin/console make:controller TestController 

Cette fois, tout devrait bien se passer.

Le contrôleur TestController est créé dans le dossier src/Controller. Examinons...

Les vues

La vue est le fichier final qui génère la page destinée à être vue par l’utilisateur. 

Elle se compose donc de HTML, de CSS, de JavaScript et de tous les éléments qui seront interprétés par le navigateur du client.

La vue peut contenir aussi de petites instructions d’un langage de template qui s’appelle Twig. Ce langage permet de faire des traitements dans la vue comme nous le ferions dans une page PHP. Par exemple, Twig permet de définir des variables, de faire des boucles, de mettre des instructions conditionnelles, mais beaucoup plus facilement qu’avec PHP. Le but est de séparer la partie développement PHP de la partie Front en HTML, CSS...

Ainsi, un intégrateur qui maîtrise Twig n’a pas besoin de développer en PHP pour mettre en place le design du site.

Toutes les vues sont rangées dans le dossier templates de l’application. Actuellement, le dossier templates contient un sous-dossier test qui a été généré par la création du contrôleur TestController. Il contient la vue index.html.twig.

Nous remarquons la présence d’un autre fichier : base.html.twig, dans le dossier templates. Il s’agit de ce qu’on appelle un layout. C’est une vue qui servira de squelette aux autres vues (voir chapitre Le moteur de template Twig).

Ouvrons...

Les composants de HttpFoundation

Tout accès à une application web se fait via une requête HTTP. Sans entrer dans les détails, une requête HTTP se compose d’un en-tête, qui contient des informations (comme par exemple : le nom de domaine du site, le type du contenu transmis…), et d’un corps (body) dans lequel sont passés les paramètres à transmettre.

La réponse du serveur suite à l’exécution de la requête a la même syntaxe. Elle contient un en-tête spécifiant également un certain nombre d’informations et le code HTML de la réponse qui sera interprété par le navigateur.

Ces deux éléments, avec toutes leurs informations, sont traduits dans Symfony par des composants de la bibliothèque HttpFoundation. Ces composants sont deux classes existantes : la classe Request et la classe Response. Reportez-vous au chapitre Le langage Objet, section Les classes, si vous avez oublié la notion de classe.

L’utilisation de ces deux classes Request et Responseest très pratique, car nous pouvons y retrouver aisément les paramètres de la requête transmise ou définir les paramètres de la réponse transmise.

Mais comment accéder à ces deux classes de Symfony ?

Il est possible d’y accéder en utilisant leur espace de noms...

L’objet Request

Nous parlerons d’objet Request, mais c’est un abus de langage. Il s’agit en fait d’un objet instancié à partir de la classe Request.

Pour utiliser l’objet Request dans une action, il est nécessaire de transmettre cet objet dans les paramètres de l’action.

Prenons l’exemple de l’action index() du TestController. Pour utiliser l’objet Request, il faut tout d’abord utiliser son espace de noms :

use Symfony\Component\HttpFoundation\Response; 

puis, vous pouvez utiliser l’objet $request en injection de dépendance dans la méthode index :

use Symfony\Component\HttpFoundation\Request; 
class TestController extends AbstractController  
{  
        #[Route('/test', name: 'app_test')] 
        public function index(Request $request)  
        {... } 

Cette utilisation peut apparaître étrange au premier abord.

Comment l’objet $request est-il instancié ?

L’objet $request est automatiquement instancié, parce qu’il est précédé du nom de la classe Request. C’est Symfony qui s’occupe de tout.

À l’intérieur de l’action, vous avez tout le loisir de consulter cet objet $request. Par exemple, pour récupérer le nom de la requête, il est possible d’utiliser la méthode getPathInfo().

Vous pouvez tester cette méthode en incluant le code suivant dans votre contrôleur TestController :

<?php 
 
namespace App\Controller; 
 
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController; 
use Symfony\Component\HttpFoundation\Response; 
use Symfony\Component\HttpFoundation\Request; 
use Symfony\Component\Routing\Annotation\Route; 
 
class TestController extends AbstractController 
{ 
    #[Route('/test', name: 'app_test')] ...

L’objet Response

Nous parlerons d’objet Response, mais c’est un abus de langage. Il s’agit en fait d’un objet instancié à partir de la classe Response.

L’objet Response définit la réponse à envoyer au navigateur client.

Contrairement à l’objet Request, il faut l’instancier à l’intérieur de l’action du contrôleur. Voici un exemple d’utilisation de l’objet Response :

<?php 
 
namespace App\Controller; 
use Symfony\Component\HttpFoundation\Request; 
use Symfony\Component\HttpFoundation\Response; 
 
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController; 
use Symfony\Component\Routing\Annotation\Route; 
 
class TestController extends AbstractController 
{ 
    /** 
     * @Route("/test", name="test") 
     */ 
    public function index(Request $request) 
    { 
         
        $reponse=new Response('Bienvenue dans Symfony');  
        return $reponse;  
    } 
} 

L’action index() retourne la réponse, qui suivra son cours pour être transformée en réponse HTTP. Cette fois, nous n’avons pas besoin de la méthode render() qui fait appel à une page Twig.

En exécutant la requête localhost:8000/test, vous obtiendrez l’affichage suivant :

Comment cela se passe-t-il quand l’action fait appel à une vue Twig ?

C’est la méthode $this->render(...) qui génère l’objet Response envoyé. 

Un objet Response est donc bien retourné systématiquement par l’action. Attention : si vous omettez de renvoyer cet objet Response, vous aurez une erreur Symfony. Le typage impose que toutes les actions du contrôleur renvoient un objet de type Response.

La méthode $this->render se trouve dans la classe AbstractController. En consultant le contenu de cette classe dans le dossier : vendor/symfony/framework-bundle/controller, nous trouvons la méthode render, qui retourne un objet Response :

protected function render(string $view, array $parameters = [], 
Response $response = null): Response 
    { 
        $content = $this->renderView($view, $parameters); 
        $response ??= new Response(); 
 
        if...

Les variables de session

1. L’utilité des variables de session

Lorsqu’un client fait une requête HTTP, elle est réceptionnée par le serveur qui la traite et renvoie une réponse au navigateur du client.

Chaque requête est indépendante des autres.

Il n’y a pas d’information qui persiste d’une requête à l’autre. Les paramètres et tout ce que vous pouvez envoyer au serveur ne sont utilisables que dans la requête qui les contient.

Il est parfois nécessaire de conserver des informations propres au client qui est connecté. Par exemple, si votre client fait une commande de produit, il serait bien de conserver l’état de son panier de commande d’une requête à l’autre.

Cet état est propre à chaque client. Même si les informations sont sauvegardées sur le serveur (en base de données par exemple), il faut pouvoir identifier celles qui correspondent au client connecté.

Il faut donc pouvoir identifier chaque client connecté.

Pour ce faire, le serveur envoie un identifiant de session, qui est stocké sur le navigateur de chaque client (c’est un cookie). Grâce à cet identifiant, il peut repérer le client à chaque fois qu’il se connecte et lui afficher son panier de commande :

Le stockage de cet identifiant de session dure tant que le navigateur est ouvert. Il disparaît à la fermeture du navigateur. Si le client se reconnecte, il devra faire une nouvelle demande d’identifiant. Cette volatilité de l’identifiant de session permet d’éviter des failles de sécurité comme le vol de l’identifiant de session.

$session = $request->getSession(); 

 $maVariable = $session->set('nom_de_ma_variable', 'valeur'); 

  $maVariable = $session->get('nom_de_ma_variable');...