Discussion - migrer vers Jinja2 pour les templates

[AlexandreDecan]

Django Template System et Jinja2 partagent beaucoup de points communs, mais aussi pas mal de petites différences de syntaxe. Historiquement, Jinja2 était 10 à 20x plus rapide que Django pour le rendu des templates, mais je n'ai aucune idée si cette affirmation est encore vraie à l'heure actuelle.

Quoiqu'il en soit, Jinja2 est un moteur de rendu proposé maintenant en standard dans Django (1.9 : https://docs.djangoproject.com/en/1.9/topics/templates/).

http://jinja.pocoo.org/docs/dev/

Outre les différences syntaxiques entre les deux, et la supposée différence de performances, Jinja2 permet d'intégrer quand nécessaire un peu de logique dans les templates, des macros, etc. Il serait peut-être intéressant de peser le pour et le contre d'une migration de DTS vers Jinja2, afin d'éviter d'utiliser certains "hacks" dans les templates à cause des limitations (justifiées, cela dit) de DTS.

Qu'en penses-tu @roidelapluie ?

[AlexandreDecan]

Quelques avantages en vrac :

• Contrôle des espaces/retours à la ligne (comme dans Nunjucks) http://jinja.pocoo.org/docs/dev/templates/#whitespace-control
• Le {%for .... recursive %} http://jinja.pocoo.org/docs/dev/templates/#for
• Les macros http://jinja.pocoo.org/docs/dev/templates/#macros
• Les affectations sans limite de portée http://jinja.pocoo.org/docs/dev/templates/#assignments (ok c'est discutable, mais dans Django, on galère parfois à réussir à utiliser un with dans un if ou dans une boucle à cause de ça)
• Le support des listes litérales dans la template http://jinja.pocoo.org/docs/dev/templates/#literals (le texte du bouton de post sur le forum utilise une astuce interdisant les whitespace dans le texte)

Quelques inconvénients :

• Travail de conversion délicat, car il faudra valider manuellement chaque template pour s'assurer que le rendu est encore correct (et valide)
• Nécessité de modifier les filtres/tags supplémentaires introduits avec Lexpage (mais ça ne devrait pas être difficile vu que dans les deux cas, il s'agit d'un décorateur !)
• Je n'ai pas encore vu de support pour un équivalent de humanize, et je ne sais pas si certains filtres standards de Django sont encore fonctionnels ({% url %}, {% static %}, etc.)

[roidelapluie]

Je connais très bien j2. La question est: est ce qu'on peut mixer les 2?

[AlexandreDecan]

Visiblement oui, en plaçant les templates dans des répertoires spécifiques pour chaque moteur. Pourquoi souhaites-tu mixer les deux ?

[roidelapluie]

Comme ça on évite une autre PR géante, on peut faire des PR avec 2/3 templates à la fois

[AlexandreDecan]

https://docs.djangoproject.com/en/1.9/topics/templates/#django.template.backends.base.Template.render

On peut effectivement mixer les deux, en séparant les sources. Si on souhaite faire une transition en douceur, c'est une bonne approche : placer les templates Jinja2 dans un répertoire parallèle dans chaque app, et dès qu'une template est prête avec Jinja2, on peut la virer du répertoire historique "templates". Quand l'ensemble est migré, on renomme le répertoire de Jinja2 en "template" (ou pas).

Je regarde pour les filtres/tags spécifiques à Django. Je suis sûr que si ça n'existe pas en builtin, quelqu'un aura pondu une extension pour supporter ça.

[roidelapluie]

On peut peut etre tester la parité jinja2/dst avec travis?

[AlexandreDecan]

Et visiblement, ce n'est pas difficile d'utiliser certains tags/filtres built-in de DTS dans Jinja2, il faut simplement les ajouter dans l'environnement.

https://docs.djangoproject.com/en/1.9/topics/templates/#django.template.backends.jinja2.Jinja2

[AlexandreDecan]

On pourrait, mais on risque d'avoir vite des différences notamment en terme d'espaces/retours à la ligne, et aussi je suppose qu'on va en profiter pour corriger quelques aberrations au passage :-D

Fondamentalement, la migration ne sera pas si factorisable que ça : les nombreux héritages/inclusions qu'on fait un peu partout vont nécessiter de dupliquer pas mal de templates à la fois dans DTS et dans Jinja2 pour garantir la transition. Ca ne va pas rendre les choses simples niveau organisation le temps de "tout migrer".

Je me demande si on peut encore charger "localement" des tags/filtres depuis un sous-répertoire "templatetags" d'une application. Je n'ai pas l'impression, et je ne vois rien dans la doc pour ça à première vue.

Tu as déjà utilisé Jinja2 dans un projet Django ? Je ne compte pas me précipiter vers une migration DTS -> Jinja2 sans méticuleusement m'assurer qu'on ne perdra pas en clarté/organisation au profit de quelques facilités d'écriture...

[roidelapluie]

Pas avec django. Mon blog utilise jinja2 par contre

[AlexandreDecan]

Il nous faudra au moins une implémentation des tags/filtres suivants :

• filtres date, naturalday, naturaltime, timesince, timeuntil (je ne suis pas sûr qu'on fait usage de ces deux derniers, par contre !)
• tag {% ifchanged %} qu'on peut sans doute implémenter sous forme de test {% if machin is changed %}
• tags {% url %}, {% static %} et {% csrf_token %} à reprendre depuis Django
• tag {% now %}
• filtre pluralize

Note que nous pouvons soit redéfinir ces tags from scratch, soit utiliser l'implémentation de Django.

Les filtres/tags suivants sont sans doute ré-écrivables autrement :

• {% regroup %} (--> y a un filtre |groupby qui semble faire la même chose ?)
• {% widthratio %} (utilisé seulement pour les étiquettes des billets je crois)

[AlexandreDecan]

Je pense qu'on va attendre Django 1.10 ou 1.11, que les gens se fassent les dents sur Jinja2 au travers de la 1.9 et remontent les bugs ;-)

[AlexandreDecan]

https://niwinz.github.io/django-jinja/latest/

[AlexandreDecan]

https://docs.djangoproject.com/fr/1.11/topics/templates/ Mais d'abord passer en 1.11 (par facilité), donc #179

[AlexandreDecan]

J'ai fait quelques tests, ils sont visibles dans la branche "jinja2". En particulier, il y a une configuration par défaut utilisant Jinja2 quand les templates sont définies (dossier "jinja2" au lieu de "templates"). J'ai converti grossièrement les templates correspondant à la page d'accueil (sidebar, navbar, etc. inclus).

Le retour que j'en fait :

• La configuration n'est pas compliquée. Par contre, l'ajout de filtres, variables globales, etc. n'est pas "idéale" dans le sens où cela se fait globalement (par opposition au module "templatetags" d'une app classique Django). Il y a sans doute moyen d'intégrer cela plus proprement dans chaque "sous-app", mais le {% load X %} de Django était bien pratique pour ne pas polluer le namespace à tout va !
• Beaucoup de petits changements à prévoir lors de la conversion des templates Django vers Jinja2, en particulier les nombreux {% url x %} devenant des {{ url(x) }}, ou encore les paramètres de filtres. Ce n'est pas dramatique, mais ça va demander du temps, surtout que Jinja2 est parfois plus souple (passage de paramètres), parfois moins souple (lookup d'une fonction unaire explicite, comme dans {{ user.is_authenticated }} qui requiert les () explicitement (à juste titre, mais ce sont des erreurs faciles à réaliser lors de la conversion !).
• Ca va être le bronx de maintenir deux versions des templates (une pour Django, une pour Jinja2) le temps de la conversion :-D

Même s'il existe déjà un middleware django-jinja2 pour faciliter le passage de l'un à l'autre, je ne suis pas convaincu que ça soit une bonne idée que d'utiliser ce middlware, car grosso-modo, on ne fait que porter les features de base de Django vers Jinja2 via de gros workarounds. A terme, ce serait bien plus propre et sain de réfléchir directement en "Jinja2". Mais est-ce que l'on veut réellement y arriver ?

Bien que j'apprécie la souplesse de Jinja2 (notamment pour faire de arithmétique ou un peu de logique procédurale), est-ce que l'absence de cette souplesse est un réel problème pour Lexpage ?