J’utilise Django depuis près de 6 ans, sans vocation professionnelle (à une exception près), c’est-à-dire sans y consacrer mes journées ou mes semaines ou alors seulement par à-coups, le temps de mener à bien un projet personnel qui, en règle générale, s’étale au mieux sur un mois ou deux.

Plusieurs fois, la tentation d’en lire la documentation d’une traite, d’un bout à l’autre, m’a traversé l’esprit. Il m’est arrivé de me lancer, et à peu près 100% de ces tentatives se sont soldées par des échecs. Non pas que sa documentation soit indigeste, ou beaucoup plus indigeste qu’une autre. Elle est même plutôt agréable, surtout si on la compare, mettons, à celle de React. Elle est même souvent plus claire, plus exhaustive et agrémentée de meilleurs exemples que celle de Flutter, malgré la meilleure volonté du monde de la part de Google. Je la range à égalité avec celle de Racket, qui a bien du mérite vu la singularité des langages fonctionnels. Mais il faut bien l’avouer, une longue litanie d’objets, de classes, de méthodes, de fonctions, de mixins, de backends, ça n’est pas toujours engageant. Comme le dictionnaire : on s’amuse encore un peu jusqu’à la lettre K, et puis passés les koalas...

Toujours est-il que bon nombre de fonctionnalités, et c’est peu dire que Django en regorge, me sont passées et me passent encore allègrement au-dessus de la tête, avec cette conséquence : on découvre un beau jour qu’il existe une solution prête à l’emploi, élégante et performante, à un problème qui vous a donné du fil à retordre et pour lequel vous avez bricolé quelque chose de bancale, de difficile à maintenir, et de probablement dangereux. Mais la solution, à force d’éplucher Stackoverflow (ah bien sûr, tout ceci précède l’arrivée de l’IA) et de vous presser les méninges, faisait alors votre fierté.

Mon problème, c’était la mise en cache des ressources par les navigateurs : CSS, scripts, favicon, etc. Car en parfait enthousiaste, au four et au moulin, au design et à la base de données, et trop heureux de pousser en production, j’itère environ 400 fois par jour quand je suis lancé dans un chantier. Itérations qui vont d’une nouvelle fonctionnalité JavaScript à une nuance de couleur légèrement plus soutenue. Rien de bien sérieux, mais un inconvénient : devoir vider le cache de mon navigateur à chaque changement effectué, pour en admirer le résultat.

Afin d’y remédier, je faisais appel à un context_processor, à deux nouveaux réglages, à une fonction pour récupérer la date et l’heure de dernière modification de mes dossiers JS et CSS et, pour finir, à un template tag dédié, et cela pour adjoindre un malheureux paramètre d’URL à ces fichiers, ce qui force les navigateurs à servir la dernière version en date, plutôt qu’une en cache.

Eh bien figurez-vous qu’il existe dans Django une sous-classe du moteur de stockage par défaut, qui se nomme ManifestStaticFilesStorage, qu’il suffit de déclarer dans son fichier settings.py, et qui s’occupe, en gros, d’automatiser tout le processus décrit ci-dessus (avec infiniment plus d’ingéniosité, évidemment, et notamment parce qu’elle utilise comme suffixe pour chaque fichier un hachage MD5 de son contenu). Et cela pour l’ensemble des fichiers statiques de votre site. Pas de context_processor, pas de modifications à faire dans vos templates, pas de code à dupliquer… Rien qu’une solution simple et gracieuse.

Ha ! RTFM…