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 ;-)