Routage et contrôleur

1. Définition

Comme nous l’avions vu dans le chapitre sur l’architecture du framework, Symfony 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.

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 utilisez...

controllers: 
   resource: 
       path: ../src/Controller/ 
       namespace: App\controller 
   type: attribute  

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 ou les attributs PHP mais également par 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 attributs, annotations ou bien les fichiers au format YAML qui sont utilisés, les formats XML et PHP étant...

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 ou attributs PHP

Selon les définitions du chapitre Architecture du framework - Le modèle de conception MVC, les actions sont des méthodes présentes dans des classes appelées « contrôleur » et c’est donc au-dessus de ces actions que nous devons placer notre règle de routage sous la forme d’annotation ou d’attribut :

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!');  
   }  
} 

Avec les annotations, nous utiliserions :

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

À noter qu’avec les attributs, il n’y a pas besoin d’utiliser une quelconque direc-tive use pour rendre visible une classe !

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’attribut ou à l’annotation.

Pour que le routage du contrôleur soit effectif, il faut qu’il soit activé dans le fichier config/routes.yaml. Pour nous faciliter la tâche...

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 :

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).

2. Exemple de mise en œuvre

Une fois vos sous-domaines configurés au niveau du système, vous êtes prêt à utiliser la fonctionnalité du routage par nom de domaine.

Configurons une route s’appuyant sur le nom de domaine, le sous-domaine correspondant à la langue du contenu :

YAML

# Dans le fichier config/routes.yaml  ...

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 publiques ; 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...