Routage

Présentation

Précédemment, pour avoir rapidement une preuve de fonctionnement du site, une page d’accueil a été mise en place, au plus simple. Ce point va maintenant être revu afin d’être développé.

En quelques mots, le routage consiste d’une part, dans le sens entrant, à établir une carte de correspondance entre les URL et des processus de traitement, et d’autre part, dans le sens sortant, à pouvoir aisément générer des URL bien formées.

Le système de routage peut être vu comme un arbre dont le point d’entrée est cité parmi les paramètres de configuration sous le nom ROOT_URLCONF. La notion de ramification est apportée par un mécanisme d’inclusion, qui fait que les définitions peuvent être réparties de façon hiérarchique.

Si on observe le fichier mysite\urls.py, on voit que l’assistant de création de projet propose d’office un routage vers les vues du module d’administration intégrée, avec l’emploi du terme admin en premier maillon des chemins d’URL :

path('admin/', admin.site.urls), 

Les maillons suivants des chemins sont établis par le paquet mentionné. Il est vain de vouloir aller plus avant dans l’intérieur de ce paquet, car il n’est pas représentatif...

Configuration des adresses

L’objectif est de continuer la mise en place du routage, avec une capacité d’adresser les vues à venir de l’application messenger. Une façon traditionnelle est d’attribuer un maillon du chemin à une application, souvent avec le même terme que le nom de l’application pour faciliter la compréhension. Dans le cas présent, ce maillon s’écrit ainsi :

mysite\urls.py 

 

from django.urls import include, path 
#... 
 #... 
 path('messenger/', include('mysite.messenger.urls')), 

La fonction include() permet de déléguer la suite de la correspondance au module mentionné, qui lui-même peut faire un nouvel étage de répartition et ainsi de suite.

Une configuration minimale d’URL est préparée pour le module messenger, en créant son fichier de routage :

mysite\messenger\urls.py 

 

from django.urls import path 
 
from .views import index 
 
urlpatterns = [ 
   path('', index), 
] 

Le plan de routage va être enrichi en préparant des URL pour répondre aux opérations de base, à savoir : lister les dossiers de réception et d’envoi, écrire...

Espace de noms

Dans la section précédente, des noms ont été donnés aux chemins d’URL. Ceci permet de reconstruire une URL dans l’autre sens, à partir d’une référence à son nom. Cette faculté, appelée résolution inversée, est largement utilisée dans les gabarits de page. On en voit aussi ici un usage, dans le fichier de routage au sein de la définition de la redirection du motif vide vers la page de réception.

Se pose alors la question de l’unicité des noms. Dans la grande majorité des cas, on voudra que la référence à un nom désigne sans ambiguïté une URL bien précise. Le problème est que les noms employés peuvent être assez ordinaires, comme index ou home, pour se retrouver dans plus d’une application. Or, lorsqu’un nom est utilisé plusieurs fois, soit au sein d’une même application (mauvaise conception), soit dans plusieurs applications (conflit de nommage), le mécanisme de recherche retient la dernière occurrence trouvée dans la liste ordonnée urlpatterns.

Une solution basique serait d’ajouter un préfixe par convention, dans le même esprit que l’idée citée à l’occasion du problème de conflit de nommage des gabarits de vues, avec le même défaut d’alourdissement des noms. Mais il faut plutôt voir cette convention d’écriture comme un artifice tendant à réduire les risques de conflit, sans s’en protéger avec certitude. De plus, elle n’est pas adaptée à l’emploi d’applications externes, qu’on n’est pas censé devoir déformer...

Instances multiples d’une même application

Pour rappel, nous n’avons pas le besoin de déployer plus d’une fois notre application, mais l’exercice va quand même être fait pour expérimenter le comportement de notre routage.

Pour mettre en œuvre l’application à deux reprises, il faut naturellement définir deux chemins d’URL distincts. On peut assez facilement se douter que si on ne définit aucun des espaces de noms des deux instances, sachant que toutes deux vont prendre par défaut l’espace de noms de l’application, cela crée une source d’ambiguïté.

En effet, les vérifications d’intégrité au démarrage du serveur détectent le caractère anormal de cette situation et un avertissement est produit :

WARNINGS: 
?: (urls.W005) URL namespace 'messenger' isn't unique. You may  
not be able to reverse all URLs in this namespace 

On pourrait laisser cette attribution par défaut à l’une des instances, mais il est préférable de nommer explicitement les deux instances. L’analyse sera plus facile à conduire et les conclusions seront les mêmes.

mysite\urls.py 

 

#... 
path('messenger1/', include( 
 'mysite.messenger.urls', namespace='inst1' 
)), 
path('messenger2/'...