• 30 hours
  • Medium

Free online content available in this course.

Videos available in this course

Certificate of achievement available at the end this course

Got it!

Last updated on 5/13/19

Le routeur de Symfony

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

Comme nous avons pu le voir, le rôle du routeur est, à partir d'une URL, de déterminer quel contrôleur appeler et avec quels arguments. Cela permet de configurer son application pour avoir de très belles URL, ce qui est important pour le référencement et même pour le confort des visiteurs. Soyons d'accord, l'URL /article/le-systeme-de-route est bien plus sexy que index.php?controleur=article&methode=voir&id=5 !

Vous avez sans doute déjà entendu parler d'URL Rewriting ? Le routeur, bien que différent, permet effectivement de faire l'équivalent de l'URL Rewriting, mais il le fait côté PHP, et donc est bien mieux intégré à notre code.

Le fonctionnement

L'objectif de ce chapitre est de vous transmettre toutes les connaissances nécessaires pour pouvoir créer les routes dont vous allez avoir besoin.

Pour rappel, chaque route fait la correspondance entre une URL et un jeu de paramètres. Le paramètre qui nous intéressera le plus est controller, qui correspond au contrôleur à exécuter.

Je vous invite à mettre dès maintenant les routes présentées au code suivant dans notre fichier de route, nous allons travailler dessus dans ce chapitre :

# config/routes.yaml

oc_advert_index:
    path:       /advert
    controller: App\Controller\AdvertController::index

oc_advert_view:
    path:       /advert/view/{id}
    controller: App\Controller\AdvertController::view

oc_advert_add:
    path:       /advert/add
    controller: App\Controller\AdvertController::add

Fonctionnement du routeur

Dans le code précédent, vous pouvez distinguer trois blocs. Chacun correspond à une route. Nous les verrons en détail plus loin, mais vous pouvez constater que chaque route prend :

  • Une entrée (ligne path) : c'est l'URL à capturer ;

  • Une sortie (ligne controller) : c'est un des paramètres de la route, celui qui indique quel contrôleur exécuter.

Le but du routeur est donc, à partir d'une URL, de trouver la route correspondante et de retourner les paramètres de sortie que définit cette route, dont le contrôleur. Pour trouver la bonne route, le routeur va les parcourir une par une, dans l'ordre du fichier, et s'arrêter à la première route qui fonctionne. La figure suivante est un schéma équivalent au chapitre précédent, mais actualisée pour nos routes actuelles.

Cheminement du routeur
Cheminement du routeur

Et voici en texte le fonctionnement, pas à pas :

  1. On appelle l'URL /advert/view/5.

  2. Le routeur essaie de faire correspondre cette URL avec le pathde la première route. Ici,/advert/view/5 ne correspond pas du tout à /advert (ligne path de la première route).

  3. Le routeur passe donc à la route suivante. Il essaie de faire correspondre /advert/view/5 avec/advert/view/{id}. Nous le verrons plus loin, mais {id} est un paramètre, une sorte de joker « je prends tout ». Cette route correspond, car nous avons bien :

    • /advert/view (URL) =/advert/view (route) ;

    • 5 (URL) = {id} (route).

  4. Le routeur s'arrête donc, il a trouvé sa route.

  5. Il demande à la route : « Quels sont tes paramètres de sortie ? », la route répond : « Mes paramètres sont 1/ le contrôleur App\Controller\AdvertController::view, et 2/ la valeur $id = 5. »

  6. Le routeur renvoie donc ces informations au Kernel (le noyau de Symfony).

  7. Le noyau exécute le bon contrôleur avec les bons paramètres !

Dans le cas où le routeur ne trouve aucune route correspondante, le noyau de Symfony déclenche une erreur 404.

Pour chaque page, il est possible de visualiser toutes les routes que le routeur essaie une à une, et celle qu'il utilise finalement. C'est le Profiler qui s'occupe de tracer cela, accessible depuis la barre d'outils : cliquez sur le nom de la route dans la barre d'outils, « oc_advert_index » si vous êtes sur la page /advert. Ce lien vous amène dans l'onglet « Request/Response » du Profiler, mais allez dans l'onglet « Routing » qui nous intéresse (sur la gauche). Vous devriez obtenir la figure suivante.

Liste des routes enregistrées par le routeur
Liste des routes enregistrées par le routeur

Vous pouvez voir que le routeur agit comme décrit plus haut : il essaie une à une les routes enregistrées, et s'arrête à la première qui correspond à l'URL. Par exemple, nos routes  oc_advert_view  et  oc_advert_add  n’apparaissent même pas, car elles sont définies après une route qui correspond !

Définir les routes dans le contrôleur

Jusqu'ici, nous avons défini nos routes dans un fichier dédié. C'est une des manières de les définir, mais il en existe une autre dont je souhaiterais vous parler : définir les routes directement depuis les contrôleurs.

Comment ? Grâce à un mécanisme que vous connaissez peut-être déjà : les annotations. Ce sont des commentaires PHP, ce qui signifie qu'ils ne perturbent pas votre code. Mais certaines bibliothèques, dont le routeur de Symfony, sont capables de lire ces commentaires et d'en extraire les informations intéressantes.

Passons à la pratique, vous comprendrez très vite !

Il nous faut installer la recette  annotations , qui permet d'utiliser plusieurs types d'annotations, dont celle qui nous intéresse pour définir les routes. Exécutez donc  composer require annotations .

Maintenant, convertissons la définition de notre route  oc_advert_index  du fichier YAML au contrôleur. Pour rappel, voici la définition en YAML (que vous pouvez supprimer) :

oc_advert_index:
    path:       /advert
    controller: App\Controller\AdvertController::index

Et voici le parfait équivalent, dans le contrôleur :

<?php
// src/Controller/AdvertController.php

namespace App\Controller;

use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Annotation\Route;
use Twig\Environment;

class AdvertController
{
  /**
   * @Route("/advert", name="oc_advert_index")
   */
  public function index(Environment $twig)
  {
    $content = $twig->render('Advert/index.html.twig', ['name' => 'winzou']);

    return new Response($content);
  }
}

D'abord, nous avons importé la classe qui nous permet de définir la route :  Symfony\Component\Routing\Annotation\Route (ligne 7).

Ensuite, nous avons ajouté l'annotation  @Route , juste avant la méthode correspondante à la route (ici,  index() ). J'insiste sur le "juste avant", car vous pouvez voir que dans l'annotation en elle-même, nous n'avons plus le paramètre  controller: xxx . Le routeur fait donc le lien entre la route et le contrôleur à exécuter en prenant la méthode qui vient juste après.

Au final, on retrouve les mêmes informations :

  • Le nom de la route en YAML est indiqué dans le  name="oc_advert_index"  de l'annotation ;

  • Le path de la route en YAML est indiqué dans le premier argument de l'annotation, ici  "/advert"  ;

  • Le controller de la route en YAML est la méthode suivant l'annotation.

Mais comment le routeur est-il au courant de cette route cachée dans le contrôleur ?

La question est pertinente, et comme toujours avec Symfony, la réponse est rationnelle, aucune magie. Lors de l'installation de la recette, Composer a ajouté le fichier  /config/routes/annotations.yaml . Ouvrez-le, il y est indiqué de rechercher des routes de type annotation dans tous les fichiers du répertoire  /src/Controller , c'est ce que fait donc le routeur !

Voilà, vous savez définir une route depuis le contrôleur ! Je le répète : définir ses routes dans des fichiers YAML ou depuis les contrôleurs est strictement équivalent. L'avantage de le faire depuis les contrôleurs est de rapprocher routes et méthodes de contrôleur, et c'est pour cette raison que c'est la syntaxe que j'utiliserai dans la suite du cours.

Les routes de base

Créer une route avec des paramètres

Vous savez maintenant créer une route simple, mais revenons un peu sur la route  oc_advert_view  qui contient un paramètre supplémentaire :  id . La voici dans le contrôleur (n'oubliez pas de la supprimer du fichier  routes.yaml ) :

<?php
// src/Controller/AdvertController.php

namespace App\Controller;

use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Annotation\Route;

class AdvertController
{
  // ...

  /**
   * @Route("/advert/view/{id}", name="oc_advert_view")
   */
  public function view($id)
  {
    // $id vaut 5 si l'URL appelée est /advert/view/5
    
    return new Response("Affichage de l'annonce d'id : ".$id);
  }
}

Grâce au paramètre {id} dans le path de notre route, toutes les URL du type /advert/view/* seront gérées par cette route, par exemple :

  • /advert/view/5 ,

  • ou /advert/view/654,

  • ou même /advert/view/azerty : on n'a pas encore dit que {id} devait être un nombre, patience !

Par contre, l'URL  /advert/view  ne sera pas interceptée, car le paramètre  {id}  n'est pas renseigné. En effet, les paramètres sont par défaut obligatoires, nous verrons quand et comment les rendre facultatifs plus loin dans ce chapitre.

Mais si le routeur s’arrêtait là, il n'aurait aucun intérêt. Toute sa puissance réside dans le fait que ce paramètre {id} est accessible depuis votre contrôleur ! Si vous appelez l'URL /advert/view/5, alors depuis votre contrôleur vous aurez la variable $id (du nom du paramètre) en argument de la méthode, variable qui aura pour valeur « 5 » !

N'oubliez pas de tester votre code à l'adresse suivante : /advert/view/5, et amusez-vous à changer la valeur du paramètre dans l'URL.

Vous pouvez bien sûr multiplier les paramètres au sein d'une même route. Créez cette route et cette méthode à la suite, pour l'exemple :

<?php
# src/Controller/AdvertController.php

/**
 * @Route("/advert/view/{year}/{slug}.{format}", name="oc_advert_view_slug")
 */
public function viewSlug($slug, $year, $format)
{
  return new Response(
    "On pourrait afficher l'annonce correspondant au
    slug '".$slug."', créée en ".$year." et au format ".$format."."
  );
}

Cette route intercepte par exemple les URL suivantes :

  • /advert/view/2011/webmaster-aguerri.html ,

  • et /advert/view/2012/symfony.xml,

  • etc.

Revenez à notre route et notez également le point entre les paramètres {slug} et {format} : vous pouvez en effet séparer vos paramètres soit avec le slash (« / »), soit avec le point (« . »). Veillez donc à ne pas utiliser de point dans le contenu de vos paramètres. Par exemple, pour notre paramètre {slug}, une URL /advert/view/2011/webmaster.aguerri.html ne va pas fonctionner comme on l'attend, car :

  • {year} = 2011 ;

  • {slug} = webmaster ;

  • {format} = aguerri.html (il prend tout le reste de l'URL).

Si on voulait que notre paramètre  slug  prenne la valeur  webmaster.aguerri , c'est raté ! Attention donc à ce petit détail. ;)

Les routes avancées

Créer une route avec des paramètres et leurs contraintes

Nous avons créé une route avec des paramètres, très bien. Mais si quelqu'un essaie d'atteindre l'URL/advert/view/sdf/azerty.bouh, eh bien, rien ne l'en empêche ! Et pourtant, « sdf » n'est pas tellement une année valide ! La solution ? Les contraintes sur les paramètres. Reprenons notre dernière route  oc_advert_view_slug .

Nous voulons ne récupérer que les bonnes URL où l'année vaut « 2010 » et non « sdf », par exemple. Cette dernière devrait retourner une erreur 404 (page introuvable). Pour cela, il nous suffit qu'aucune route ne l'intercepte ; ainsi, le routeur arrivera à la fin du fichier sans aucune route correspondante et il déclenchera tout seul une erreur 404.

Comment faire pour que notre paramètre {year} n'intercepte pas « sdf » ? Il faut ajouter des contraintes sur nos paramètres :

/**
 * @Route("/advert/view/{year}/{slug}.{format}", name="oc_advert_view_slug", requirements={
 *   "year"   = "\d{4}",
 *   "format" = "html|xml"
 * })
 */

Nous avons ajouté la section requirements. On utilise les expressions régulières pour déterminer les contraintes que doivent respecter les paramètres. Ici :

  • \d{4} veut dire « quatre chiffres à la suite ». L'URL /advert/view/sdf/webmaster.html ne sera donc pas interceptée car "sdf" n'est pas une suite de 4 chiffres.

  • html|xml signifie « soit HTML, soit XML ». L'URL /platform/2011/webmaster.rss ne sera donc pas interceptée.

Maintenant, nous souhaitons aller plus loin. En effet, si le « .xml » est utile pour récupérer l'annonce au format XML (pourquoi pas ?), le « .html » semble inutile : par défaut, le visiteur veut toujours du HTML. Il faut donc rendre le paramètre {format} facultatif.

Utiliser des paramètres facultatifs

Reprenons notre route et ajoutons-y la possibilité pour {format} de ne pas être renseigné :

/**
 * @Route("/advert/view/{year}/{slug}.{format}", name="oc_advert_view_slug", requirements={
 *   "year"   = "\d{4}",
 *   "format" = "html|xml"
 * }, defaults={"format" = "html"})
 */

Nous avons ajouté un quatrième argument à l'annotation, le tableau  defaults , contenant un seul élément : format = html.

Ainsi, l'URL /advert/view/2014/webmaster sera bien interceptée et le paramètre format prendra sa valeur par défaut, à savoir « html ». Au niveau du contrôleur, rien ne change : vous gardez l'argument$format comme avant et celui-ci vaudra « html », la valeur par défaut.

Utiliser des « paramètres système »

Prenons l'exemple de notre paramètre {format} : lorsqu'il vaut « xml », vous allez afficher du XML et devrez donc envoyer le header avec le bon Content-type. Les développeurs de Symfony ont pensé à nous et prévu des « paramètres système ». Ils s'utilisent exactement comme des paramètres classiques, mais le Kernel de Symfony va effectuer automatiquement des actions supplémentaires lorsqu'il les détecte.

Le paramètre {_format} 

Lorsqu'il est utilisé (comme notre paramètre {format}, ajoutez juste un underscore), alors un header avec le Content-Type correspondant est ajouté à la réponse retournée. Exemple : vous appelez/advert/view/2014/webmaster.xml et le Kernel sait que la réponse retournée par le contrôleur est du XML, grâce au paramètre "_format" contenu dans la route. Ainsi, avant d'envoyer la réponse à notre navigateur, le header Content-Type: text/xml sera ajouté.

Faites le test : modifiez le nom du paramètre de la route à {_format} , n'oubliez pas de changer le nom de l'argument de la méthode viewSlug à $_format  également (nom du paramètre dans la route = nom de l'argument dans la méthode du contrôleur). Enfin, essayez d'atteindre la page /platform/2019/webmaster.xml. J'utilise dans la figure suivante l'outil de développement de Chrome pour afficher les en-têtes de la réponse HTTP envoyée par notre page.

Vérification que le header de la réponse HTTP est correct
Vérification que le header de la réponse HTTP est correct

L'erreur en rouge affichée par mon navigateur Chrome (peut être différent si vous utilisez un autre navigateur) est due au fait que le contenu de la réponse est du texte (la phrase "On pourrait afficher..." que nous avons écrite dans le contrôleur), alors que le Content-Type de la réponse est XML. Chrome n'est pas content car ce n'est pas du XML valide. Nous devrions renvoyer un XML proprement formé, mais‌ ce n'est pas grave, c'est pour l'exemple.

Le paramètre {_locale} 

Lorsqu'il est utilisé, il définit la langue dans laquelle l'utilisateur souhaite obtenir la page. Ainsi, si vous avez défini des fichiers de traduction ou si vous employez des bundles qui en utilisent, alors les traductions dans la langue du paramètre {_locale} seront chargées. Pensez à mettre unrequirements sur la valeur de ce paramètre pour éviter que vos utilisateurs ne demandent le russe alors que votre site n'est que bilingue français-anglais.

Ajouter un préfixe lors de l'import de nos routes

Vous avez remarqué que nous avons mis /advert  au début du path de chacune de nos routes. En effet, on crée un site et on aimerait que tout ce qui touche aux annonces ait ce préfixe /advert. Au lieu de le répéter dans chaque route, Symfony vous propose de rajouter un préfixe pour toutes les routes d'un même fichier ou contrôleur.

Pour un contrôleur, ajoutez donc cette annotation sur la classe et non sur une méthode, comme suit :

<?php
// src/Controller/AdvertController.php

/**
 * @Route("/advert")
 */
class AdvertController
{
  // ...
}

Grâce à cette annotation sur la classe tout entière, vous pouvez enlever la partie /advert de chacune de vos routes définies dans cette classe.

Bonus : si un jour vous souhaitez changer /advert par /awesomeAdvert, vous n'aurez à modifier qu'une seule ligne. ;)

Générer des URL

Pourquoi générer des URL ?

J'ai mentionné précédemment que le routeur pouvait aussi générer des URL à partir du nom des routes. En effet, vu que le routeur a toutes les routes à sa disposition, il est capable d'associer une route à une certaine URL, mais également de reconstruire l'URL correspondante à une certaine route. Ce n'est pas une fonctionnalité annexe, mais bien un outil puissant que nous avons là !

Par exemple, nous avons une route nommée « oc_advert_view » qui écoute l'URL /advert/view/{id}. Vous décidez un jour de raccourcir vos URL et vous aimeriez bien que vos annonces soient disponibles depuis /advert/v/{id}. Si vous aviez écrit toutes vos URL à la main dans vos templates, vous auriez du toutes les changer à la main, une par une. Grâce à la génération d'URL, vous ne modifiez que la route : ainsi, toutes les URL générées seront mises à jour ! C'est un exemple simple, mais vous pouvez trouver des cas bien réels et tout aussi gênants sans la génération d'URL.

Comment générer des URL ?

1. Depuis le contrôleur, avec injection

Pour générer une URL, vous devez le demander au routeur en lui donnant deux arguments : le nom de la route ainsi que les éventuels paramètres de cette route.

Pour récupérer l'objet routeur, il faut utiliser le même mécanisme que nous avions utilisé pour l'objet Twig. Ensuite, c'est la méthode  generate  qui nous permet de générer une URL à partir du nom d'une route ainsi que de ses paramètres. Par exemple :

<?php
// src/Controller/AdvertController.php

namespace App\Controller;

use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Annotation\Route;
use Symfony\Component\Routing\RouterInterface;

/**
 * @Route("/advert")
 */
class AdvertController
{
  /**
   * @Route("/", name="oc_advert_index")
   */
  public function index(RouterInterface $router)
  {
    $url = $router->generate(
        'oc_advert_view', // 1er argument : le nom de la route
        ['id' => 5]       // 2e argument : les paramètres
    );
    // $url vaut « /advert/view/5 »

    return new Response("L'URL de l'annonce d'id 5 est : ".$url);
  }
}

La méthode generate a besoin de 2 argument :

  1. Le premier est le nom de la route ;

  2. Le deuxième est un tableau contenant les valeurs des paramètres pour la génération. En effet, l'objectif du routeur n'est pas de générer /advert/view/{id}  qui n'aurait pas de sens, mais de générer une URL prête à être utilisée, dans notre cas de l'annonce d'id 5 : /advert/view/5 . Ce deuxième argument est bien sûr facultatif si votre route n'utilise pas de paramètre.

Pour générer une URL absolue, comprenant le nom de domaine, lorsque vous l'envoyez par e-mail par exemple, il faut définir le troisième argument de la méthode generate  àUrlGeneratorInterface::ABSOLUTE_URL. Exemple :

<?php

use Symfony\Component\Routing\Generator\UrlGeneratorInterface;

$url = $router->generate('oc_advert_list', [], UrlGeneratorInterface::ABSOLUTE_URL);

Ainsi, $url vaut http://monsite.com/advert et pas uniquement /advert.

2. Depuis le contrôleur, avec héritage

La méthode que nous venons de voir est la plus brute : on utilise directement l'objet du routeur. Cela vous permet de bien comprendre comment les choses fonctionnent. Il me semblait important de commencer par là.

Mais il existe une méthode encore plus simple, qui comprend quelques raccourcis, à la fois pour le routeur mais aussi pour d'autres méthodes dont on reparlera plus tard. Il faut pour cela faire hériter notre contrôleur d'une classe de Symfony :

<?php
// src/Controller/AdvertController.php

namespace App\Controller;

use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Annotation\Route;

/**
 * @Route("/advert")
 */
class AdvertController extends AbstractController // Notez l'héritage
{
  /**
   * @Route("/", name="oc_advert_list")
   */
  public function index()
  {
    $url = $this->generateUrl(
        'oc_advert_view', // 1er argument : le nom de la route
        ['id' => 5]       // 2e argument : les paramètres
    );
    // $url vaut « /advert/view/5 »

    return new Response("L'URL de l'annonce d'id 5 est : ".$url);
  }
}

Nous avons fait trois changements :

  • Ligne 13 : notre contrôleur hérite de  AbstractController , une classe de Symfony ;

  • Ligne 18 : inutile d'injecter l'objet Router ;

  • Ligne 20 : nous utilisons directement la méthode  $this->generateUrl()  plutôt que la méthode  $router->generate() .

Cette méthode est strictement équivalente à ce que nous avions fait jusqu'ici. Vous pouvez le vérifier en allant regarder le contenu de la méthode  generateUrl  : elle ne fait qu'appeler la méthode  generate  du routeur, rien de magique !

C'est la méthode que j'utiliserai dans la suite de ce cours.

3. Depuis un template Twig

Vous aurez bien plus l'occasion de générer une URL depuis les templates que depuis un contrôleur. Pour ce faire, c'est la fonction path qu'il faut utiliser depuis un template Twig :

{# Dans une vue Twig, en considérant bien sûr
   que la variable advertId est disponible #}

<a href="{{ path('oc_advert_view', { 'id': advertId }) }}">
    Lien vers l'annonce d'id {{ advertId }}
</a>

Et pour générer une URL absolue depuis Twig, pas de troisième argument, mais on utilise la fonction url() au lieu de path(). Elle s'utilise exactement de la même manière, seul le nom change. Pas de panique par rapport à la syntaxe de Twig, nous l'étudions en détails dans le prochain chapitre.

Bien sûr, ces fonctions  url  et  path  côté Twig utilisent en réalité toutes les deux la méthode  generate  du routeur. Ce n'est qu'une façon différente d'appeler le routeur, mais c'est toujours le routeur qui s'occupe de générer des URL, personne d'autre !

Voilà : vous savez générer des URL. Pensez bien à utiliser la fonction {{ path }} pour tous vos liens depuis vos templates. :)

Application : les routes de notre plateforme

Construction des routes

Revenons à notre plateforme d'échange. Maintenant que nous savons créer des routes, je vous propose de faire un premier jet de ce que seront nos URL. Voici les routes que je vous propose de créer, libre à vous d'en changer.

Page d'accueil

On souhaite avoir une URL très simple pour la page d'accueil de la partie annonces : /advert. Comme /advert est défini comme préfixe lors du chargement des routes de notre contrôleur, le path de notre route est «/». Cette page va lister les dernières annonces. Mais on veut aussi pouvoir parcourir les annonces plus anciennes, donc il nous faut une notion de page. En ajoutant le paramètre facultatif{page}, nous aurons :

/advert

page = 1

/advert/1

page = 1

/advert/2

page = 2

C'est plutôt joli, non ? Pour construire cette route il nous faut utiliser les sections :

  • requirements  : pour ne prendre que des chiffres comme numéro de page ;

  • defaults  : pour rendre facultatif le numéro de page.

Voici ce que cela donne :

<?php
/**
 * @Route("/{page}", name="oc_advert_index", requirements={"page" = "\d+"}, defaults={"page" = 1})
 */
public function index()
Page de visualisation d'une annonce

Pour la page de visualisation d'une annonce, il faut bien penser au paramètre {id} qui nous servira à récupérer la bonne annonce côté contrôleur. Voici la route :

<?php
/**
 * @Route("/view/{id}", name="oc_advert_view", requirements={"id" = "\d+"})
 */
public function view($id)
Ajout, modification et suppression

Ces routes sont sur le même format que les précédentes :

<?php
/**
 * @Route("/add", name="oc_advert_add")
 */
public function add()
{
}

/**
 * @Route("/edit/{id}", name="oc_advert_edit", requirements={"id" = "\d+"})
 */
public function edit($id)
{
}

/**
 * @Route("/delete/{id}", name="oc_advert_delete", requirements={"id" = "\d+"})
 */
public function delete($id)
{
}

N'oubliez pas de bien ajouter le préfixe /advert  en annotation de classe du contrôleur si ce n'est pas déjà fait

Pour conclure

Ce chapitre est terminé, et vous savez maintenant tout ce qu'il faut savoir sur le routeur et les routes.

Retenez que ce système de routes vous permet premièrement d'avoir des belles URL, et deuxièmement de générer des URL. Cela vous donne un système extrêmement flexible et maintenable. Le tout sans trop d'efforts !

Pour plus d'informations sur le système de routes, n'hésitez pas à lire la documentation officielle.

En résumé

  • Une route est composée au minimum de deux éléments : l'URL à faire correspondre (son path), et le contrôleur à exécuter (paramètre controller).

  • Le routeur essaie de faire correspondre chaque route à l'URL appelée par l'internaute, et ce dans l'ordre d'apparition des routes : la première route qui correspond est sélectionnée.

  • Une route peut contenir des paramètres, facultatifs ou non, représentés par les accolades {paramètre}, et dont la valeur peut être soumise à des contraintes via la section requirements.

  • Le routeur est également capable de générer des URL à partir du nom d'une route, et de ses paramètres éventuels.

  • Le code du cours tel qu'il doit être à ce stade est disponible sur la branche iteration-4 du dépôt Github.

Example of certificate of achievement
Example of certificate of achievement