05 Routage d'URL

Contrôleur frontal : définition

Un contrôleur frontal est un composant dont le rôle est d'aiguiller les requêtes émises par les utilisateurs d'une application vers les contrôleurs applicatifs adéquats.

Pour réaliser cette tâche les contrôleurs frontaux, que l'on appelle aussi parfois dispatchers, associent des patterns d'URL avec des noms de contrôleurs.

Notre exemple

Dans notre application games_review, les utilisateurs pourront accéder à la page d'accueil qui listera l'ensemble des revues de jeux ainsi qu'aux différentes revues. Pour cela il auront à leur disposition ces deux patterns d'URL:

• / devra afficher la page d'accueil.
• /jeux/[slug_du_jeu]/ devra afficher la revue du jeu ayant le slug slug_du_jeu.

Bien entendu l'affichage d'un jeu et de la page d'accueil feront l'objet d'un contrôleur respectif.

Notre contrôleur frontal (front controller) devra donc rediriger les requêtes / vers le contrôleur gérant l'affichage de la page d'accueil et les requêtes /jeux/[slug_du_jeu]/ vers notre contrôleur gérant l'affichage des revues de jeu.

Le fichier urls.py

Sous Django, chaque projet dispose d'un contrôleur frontal.

Dans le cadre de notre projet games_plus, un fichier urls.py existe donc par défaut dans le répertoire games_plus/games_review/.

Délégation aux applications

Pour rendre les applications très modulaires et réutilisables, il est possible de faire en sorte que le projet délègue une partie de la gestion des règles d'aiguillages à différentes applications. Ainsi, chaque application est responsable du routage interne des URL la concernant.

Dans le cadre de notre projet, l'ensemble des règles relatives aux jeux, page d'accueil, etc. sera géré par l'application games_review. Django implémente ceci de manière très élégante, en permettant la création d'un fichier urls.py dans le répertoire de l'application elle-même, puis en aiguillant un ensemble de requêtes depuis le contrôleur frontal d'un projet vers le contrôleur frontal de l'application.

Voyons à présent de quoi il en retourne concrètement.

Écriture du contrôleur frontal du projet

Commençons par écrire le contrôleur frontal du projet… ou plutôt le compléter, car nous l'avons déjà édité pour activer l'interface d'administration par scaffolding, rappelez-vous !

games_plus/games_plus/urls.py

from django.urls import path, include
from django.contrib import admin
from django.conf import settings
from django.conf.urls.static import static


urlpatterns = [
    path('admin/', admin.site.urls),
    path('', include('games_review.urls')),
]


if settings.DEBUG:
    urlpatterns += static(settings.STATIC_URL, document_root=settings.STATIC_ROOT)
    urlpatterns += static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)

Nous avons simplement ajouté une ligne au fichier existant. Cette ligne permet en substance de dire à Django : « Je veux que tu rediriges toutes les requêtes faites à la racine (^) vers le contrôleur frontal de l'application « games_review » qui est défini dans le module games_review.urls.

Il nous reste maintenant à (enfin !) définir nos routes vers les contrôleurs dédiés. Nous allons le faire dans le fichier urls.py de l'application.

Écriture du contrôleur frontal d'une application

Dans le répertoire de l'application, créons un fichier nommé urls.py, et écrivons-y nos règles de routage :

games_review/urls.py

Pour votre culture générale, avant la version 2.0 Django utilisé massivement les regex pour la configuration d'url. Depuis la version 2, nous pouvons utiliser les path !

Avant la version 2.0

from django.urls import url
from games_review import views
app_name = 'games_review'


urlpatterns = [
    url(r'^$', views.index, name='index'),
    url(r'^jeu/(?P<slug>[\w-]+)/$', views.game, name='game'),
]

Comme vous le remarquez, chaque règle de routage est définie selon la syntaxe suivante : url(pattern, contrôleur de destination, nom)

• Le pattern est en fait une expression régulière (comme c'est souvent le cas dans les frameworks MVC).
• Le contrôleur de destination est une fonction définie dans le fichier des contrôleurs (views) de l'application.
• Le nom de la règle de routage est utilisé pour le routage inverse.

Après la version 2.0

from django.urls import path
from games_review import views
app_name = 'games_review'


urlpatterns = [
    path('', views.index, name='index'),
    path('jeu/<slug:slug>', views.game, name='game'),
]

Comme vous le remarquez, chaque règle de routage est définie selon la syntaxe suivante : path(pattern, contrôleur de destination, nom)

• Le pattern supporte désormais la coercion de type (int, slug, etc..), dans notre exemple le premier slug correspond au type et le second au nom de la variable. Plus d'infos
• Le contrôleur de destination est une fonction définie dans le fichier des contrôleurs (views) de l'application.
• Le nom de la règle de routage est utilisé pour le routage inverse.

OK, notre contrôleur frontal est en place. Essayons d'accéder à l'une des URL définies pour voir ce qui se passe.

Vous obtenez une exception c'est naturel, nous n'avons pas encore défini de fonction associé à notre path !