Intergiciels
Introduction
Le terme « intergiciel » sera utilisé pour désigner ce que la documentation en langue anglaise appelle middleware et ce que d’autres peuvent appeler « logiciel médiateur ». Le préfixe inter ou middle souligne clairement qu’il s’agit d’un morceau de logiciel placé à la frontière entre deux blocs importants dans la chaîne de traitement de l’information. S’agissant de Django, la chaîne dans laquelle le but est d’insérer les maillons est celle du traitement d’un verbe HTTP, à la fois dans le sens entrant, pour la requête, mais aussi dans le sens sortant, pour la réponse.
Le thème a été succinctement abordé dans le chapitre Création de site à l’occasion du parcours du fichier de configuration. Il n’y était mentionné que des composants déjà inclus dans l’infrastructure logicielle, mais il est aussi possible d’écrire ses propres composants.
Pour expérimenter la création d’un intergiciel, le travail va porter à nouveau sur le sujet de la prise de traces des requêtes SQL étudié dans le chapitre Traces et journalisation. Imaginons que la solution par journalisation ne soit pas proposée ; hypothèse tout à fait plausible...
Création d’une application dédiée à l’outillage
L’intergiciel à créer pourrait être logé au sein de l’application messenger, mais puisque le service rendu n’est pas spécifique à cette application, il est plus propre de le déporter dans une application générique. Ainsi, celle-ci pourra être réutilisable pour d’autres projets. Elle pourra aussi être enrichie ultérieurement avec d’autres fonctionnalités potentielles. Puisque la réflexion s’oriente vers une boîte à outils, nommons cette application toolbox.
Créez cette application :
D:\dj>cd mysite
D:\dj\mysite>py ..\manage.py startapp toolbox
L’assistant a joué son rôle en apportant des squelettes de fichiers, mais la plupart ne seront pas utilisés étant donné le rôle spécial assigné à cette application. Rien n’empêche de les laisser et de les ignorer. Pourtant, ils peuvent être perçus comme du bruit sur le plan de la maintenance, car ils pourraient soulever des questions et des doutes sur la raison ou la nécessité de leur présence. Pour couper court à ces incertitudes, le plus pragmatique est de les éliminer tout de suite. Au pire, il sera toujours possible d’amener un exemplaire...
Implémentation d’un intergiciel
1. Mise en place du cadre
Les intergiciels peuvent se situer n’importe où, du moment qu’ils sont visibles du chemin Python. Il n’y a pas de bénéfice à faire l’original, alors faisons comme tout le monde et écrivons les composants dans un fichier nommé middleware.py (au singulier même s’il héberge plusieurs composants).
La façon d’écrire un intergiciel et le nom du paramètre de configuration ont été entièrement révisés dans la version 1.10.
Pour assurer une continuité de compatibilité, il a suffi que les composants écrits dans l’ancien style héritent de ce nouvel auxiliaire pour ne pas nécessiter d’autres refontes de codage :
django.utils.deprecation.MiddlewareMixin
Django a adopté cette technique pour les intergiciels fournis avec son code, ainsi que beaucoup d’auteurs de paquets tiers. Ceci explique pourquoi on n’y trouve pas d’écriture dans le nouveau style. N’étant pas contraint à ce devoir, le code présenté sera exprimé avec la syntaxe la plus récente.
La première démarche consiste à poser le squelette, tel qu’il est donné dans la documentation, en ajoutant seulement deux instructions de trace pour temporairement faire la preuve du bon fonctionnement :
Créez le module de l’intergiciel :
mysite\toolbox\middleware.py
class WatcherMiddleware:
def __init__(self, get_response):
self.get_response = get_response
def __call__(self, request):
print('avant la vue')
response = self.get_response(request)
print('après la vue')
return response
Ajoutez l’intergiciel à la liste, dans les paramètres de configuration :
mysite\settings.py
MIDDLEWARE = [
'mysite.toolbox.middleware.WatcherMiddleware',
# [...]
]
L’ordre des éléments dans la liste a son importance, car ces éléments doivent être considérés...