Blog ENI : Toute la veille numérique !
-25€ dès 75€ sur les livres en ligne, vidéos... avec le code FUSEE25. J'en profite !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. Symfony 4 (LTS)
  3. Routage et contrôleur
Extrait - Symfony 4 (LTS) Développez des sites web PHP structurés et performants
Extraits du livre
Symfony 4 (LTS) Développez des sites web PHP structurés et performants
1 avis
Revenir à la page d'achat du livre

Routage et contrôleur

Fonctionnement du routage dans Symfony

1. Définition

Comme nous l’avions vu dans le chapitre sur l’architecture du framework, le framework n’utilise pas la mise en relation entre l’URL et le système de fichiers pour servir les pages web.

Les URL sont gérées par le routage (composant Router du framework). Le rôle de ce composant est de trouver l’action à exécuter pour une requête donnée et pour cela, il s’appuie sur un ensemble de règles de routage définies par le développeur.

Si vous êtes familier des systèmes de réseaux, vous avez probablement déjà entendu parler de ce terme, voire du routeur. Dans un contexte applicatif, cela correspond à l’action sélectionnée pour une requête donnée ; les actions sont contenues dans des contrôleurs sous forme de méthodes.

2. Le répertoire public et le contrôleur frontal

À la racine de votre projet, vous avez un répertoire nommé public. Il contient tous vos fichiers publics. Ce sont typiquement des images, des feuilles de style CSS, des fichiers de scripts JavaScript, et, plus largement, tous les fichiers destinés à être servis directement par le serveur web.

Pour l’URL http://monjournal.local/robots.txt (ou bien http://localhost:8000/robots.txt si vous...

Définition des routes

Une route est une règle de routage. Chaque route est constituée de différentes règles, et pointe vers une action donnée.

Par défaut, le fichier de routage de l’application est config/routes.yaml, celui-ci étant complété par les fichiers se trouvant dans config/routes/ ; dans ce dernier, on trouve notamment le fichier annotations.yaml permettant d’activer la configuration du routage via des annotations :

controllers: 
   resource: ../../src/Controller/ 
   type: annotation 
 
kernel: 
   resource: ../../src/Kernel.php 
   type: annotation 

1. Les différents formats de définition

Comme évoqué dans le chapitre Mise en place d’un projet Symfony, section Structure de l’application, il existe différentes manières de définir la configuration d’une application Symfony : via des annotations et/ou via des fichiers de configuration. Plusieurs formats sont disponibles pour les fichiers de configuration : YAML (YAML Ain’t Markup Language), XML (eXtensible Markup Language) ou PHP.

En ce qui concerne le routage, ce sont principalement les annotations et les fichiers au format YAML qui sont utilisés, les formats XML et PHP étant, de manière général dans Symfony, de plus en plus délaissés....

Configurer le path

1. Illustration par l’exemple : /hello/world

La règle de routage la plus importante est le path ; elle correspond à la variable superglobale $_SERVER[’PATH_INFO’].

Configurons une route pour un path donné :/hello/world.

Annotations

Selon les définitions du chapitre Architecture du framework - Le modèle de conception MVC, les actions sont des méthodes de classe dites « contrôleur » et c’est donc au-dessus des actions que nous devons placer notre règle de routage sous forme d’annotation :

namespace App\Controller; 
 
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController; 
use Symfony\Component\HttpFoundation\Response; 
use Symfony\Component\Routing\Annotation\Route; 
 
class WelcomeController extends AbstractController  
{  
   /**  
    * @Route("/hello/world")  
    */  
   public function hello()  
   {  
       return new Response('Hello world!');  
   }  
} 

Ici, l’action hello sera exécutée pour toute requête dont le path est /hello/world, cette règle de routage étant définie grâce à l’annotation @Route.

Pour que le routage du contrôleur soit effectif, il faut qu’il soit activé dans le fichier config/routes/annotations.yaml. Pour nous faciliter la tâche, Symfony autorise la configuration de tous les contrôleurs d’une application en référençant un dossier en tant que ressource ; c’est d’ailleurs la configuration par défaut présente dans ce fichier :

controllers: 
   resource: ../../src/Controller/ 
   type: annotation 

Une fois les règles de routage configurées, le fait de demander l’URL http://monjournal.local/hello/world au travers de votre navigateur affiche une page blanche dont le contenu est « Hello world! ».

Le nom des routes avec les annotations

Nous allons voir ci-dessous avec les autres formats qu’un nom doit être assigné aux routes. Avec les annotations, ce n’est pas obligatoire car un nom est généré...

Routage par nom de domaine

1. Prérequis

Nous avons pour l’instant utilisé l’URL pour configurer nos routes, mais il est également possible d’utiliser le nom de domaine.

Cette fonctionnalité semble moins utile au premier abord car un site web est généralement accessible via un seul et unique nom de domaine, mais elle permet principalement la gestion des sous-domaines. Grâce à elle, les domaines www.example.com, admin.example.com, fr.example.com ou mobile.example.com peuvent être interprétés différemment par le routeur du framework.

Cette technique est très répandue sur le Web, le site étant alors « cloisonné » en plusieurs parties autonomes :

  • des sections pour les smartphones/tablettes (par exemple m.example.com, tablet.example.com ou mobile.example.com),

  • des sections pour les différentes langues disponibles (par exemple fr.example.com ou en.example.com),

  • des sections pour chaque espace du site (par exemple admin.example.com ou payment.example.com).

Cela peut également s’avérer efficace pour les gestionnaires de sites de publication de contenu (par exemple des blogs), où l’on peut imaginer un zonage par utilisateur, le sous-domaine étant, par exemple, le nom d’utilisateur du membre en question (jean.example.com ou lucie.example.com).

Avant de vous aventurer dans le routage par nom de domaine, il vous faut créer les différents sous-domaines que votre site web utilise. Cette procédure est décrite dans le chapitre Mise en place d’un projet Symfony - Configurer son serveur web.

2. Exemple de mise en œuvre

Une fois vos sous-domaines...

Le contrôleur

Les contrôleurs sont des éléments centraux car ils contiennent la logique de votre application. Ils disposent de plusieurs fonctionnalités, mises à leur disposition par différents services.

Vous pouvez apercevoir ces fonctionnalités en parcourant la classe Symfony\Bundle\FrameworkBundle\Controller\AbstractController, dont vos contrôleurs héritent. Chaque méthode fait appel à un service du Service Container, ces méthodes correspondant à des raccourcis.

1. Modèle de programmation et règles

Un contrôleur est une classe PHP qui doit étendre la classe Symfony\Bundle\FrameworkBundle\Controller\AbstractController. Cet héritage permet de bénéficier de mécanismes forts comme la recherche de services dans le Service Container ainsi que de l’injection de dépendances dans les méthodes. Au-delà de cette contrainte d’héritage, les classes doivent être nommées avec le suffixe Controller (WelcomeController, AdminController, etc.).

Les actions du contrôleur sont des méthodes d’instance publique ; leur nom est libre contrairement aux versions précédentes du framework, où elles devaient impérativement se terminer par le suffixe Action.

2. Travailler avec les services

Tous les services sont accessibles depuis le contrôleur. Pour y accéder, il suffit d’invoquer la méthode get(’id_du_service’).

public function index()  
{  
   $monService = $this->get('mon_service');  
   // Récupère le service dont l'identifiant est 'mon_service'  
   // ...  
} 

Cette méthode est aussi bien capable de récupérer les services du framework que vos services personnalisés. Pour plus d’informations sur les services, reportez-vous au chapitre L’injection de dépendances.

3. Utiliser les paramètres de substitution

Jusqu’à présent, vos actions étaient des méthodes sans arguments. Sachez que Symfony dispose d’une fonctionnalité de « paramètres magiques ».

Si un paramètre possède un nom ou un typage d’objet particulier...