Par sa nature liée au Web, Django a besoin d’un procédé agile de génération dynamique de HTML. L’approche la plus couramment utilisée est de se baser sur des gabarits. Un gabarit contient la partie statique du résultat HTML souhaité ainsi qu’une certaine syntaxe particulière définissant comment insérer le contenu dynamique. Pour un exemple pratique de création de pages HTML avec des gabarits, consultez la partie 3 du tutoriel.
\nUn projet Django peut être configuré avec un ou plusieurs moteurs de gabarit (ou même aucun si vous n’utilisez pas de gabarit). Django est livré avec des moteurs intégrés pour son propre système de gabarits, appelé de manière originale le langage de gabarits de Django (DTL), ainsi que pour l’alternative répandue Jinja2. Des moteurs pour d’autres langages de gabarits peuvent être mis à disposition par des applications tierces. Il est aussi possible d’écrire son propre moteur, voir Moteur de gabarit personnalisé.
\nDjango définit une API standard pour le chargement et la production de gabarits de manière indépendante du moteur utilisé. Le chargement consiste à trouver le gabarit correspondant à un identifiant donné et à le pré-traiter, ce qui revient généralement à le compiler dans une représentation en mémoire. La production consiste à interpoler le gabarit en fonction de données de contexte et à renvoyer le texte résultant.
\nLe langage de gabarits de Django est le système de gabarits propre à Django. Jusqu’à Django 1.8, il s’agissait de la seule option disponible. C’est une bonne bibliothèque de gabarit, même si son approche est parfois un peu rigide et présente quelques particularités. SI vous n’avez pas de motivation précise pour choisir un moteur différent, nous vous recommandons de travailler avec ce langage, à plus forte raison si vous écrivez une application réutilisable et que vous pensez distribuer des gabarits. Les applications contribuées de Django qui comprennent des gabarits, telle que django.contrib.admin, utilisent le moteur de Django.
\nPour des raisons historiques, la prise en charge générique des moteurs de gabarit et l’implémentation du langage de gabarit de Django se trouvent tous deux dans l’espace de noms django.template.
Un gabarit Django est un document texte ou un chaîne Python, balisés à l’aide du langage de gabarit de Django. Certaines structures sont reconnues et interprétées par le moteur de gabarit. Les principales sont les variables et les balises.
\nUn gabarit est produit avec un contexte. Le processus de production remplace les variables par leurs valeurs qui sont cherchées dans le contexte, et il exécute les balises. Tout le reste est affiché tel quel.
\nLa syntaxe du langage de gabarit de Django implique quatre structures.
\nUne variable affiche une valeur à partir du contexte, qui est un objet de type dictionnaire faisant correspondre des clés à des valeurs.
\nLes variables sont entourées par {{ et }} comme ceci :
My first name is {{ first_name }}. My last name is {{ last_name }}.\nAvec un contexte {'first_name': 'John', 'last_name': 'Doe'}, ce gabarit produit :
My first name is John. My last name is Doe.\nLa consultation de dictionnaire, d’attribut et d’indice de liste est implémentée par une notation pointée :
\n{{ my_dict.key }}\n{{ my_object.attribute }}\n{{ my_list.0 }}\nSi le contenu d’une variable s’avère être un objet exécutable, le système de gabarit l’appelle sans paramètre et utilise son résultat à la place de l’objet exécutable.
\nLes filtres transforment les valeurs de variables et les paramètres de balises.
\nIls ressemblent à ceci :
\n{{ django|title }}\nAvec un contexte {'django': 'the web framework for perfectionists with deadlines'}, ce gabarit produit le résultat suivant :
The Web Framework For Perfectionists With Deadlines\nCertains filtres acceptent un paramètre :
\n{{ my_date|date:"Y-m-d" }}\nUne référence des filtres intégrés est disponible tout comme des instructions pour écrire des filtres personnalisés.
\nLes commentaires ressemblent à ceci :
\n{# this won't be rendered #}\nUne balise {% comment %} autorise des commentaires sur plusieurs lignes.
django.template.Engine encapsule une instance du système de gabarit de Django. La raison principale de créer directement une telle instance est d’utiliser le langage de gabarit de Django en dehors d’un projet Django.
django.template.backends.django.DjangoTemplates est un adaptateur léger autour de django.template.Engine pour l’adapter à l’API de moteur de gabarit de Django.
django.template.Template représente un gabarit compilé. Les gabarits sont obtenus par Engine.get_template() ou Engine.from_string().
De même, django.template.backends.django.Template est un adaptateur léger autour de django.template.Template pour l’adapter à l’API de gabarit commune.
django.template.Context contient des métadonnées en plus des données de contexte. Il est transmis à Template.render() en vue de la production d’un gabarit.
django.template.RequestContext est une sous-classe de Context qui stocke la requête HttpRequest en cours et exécute les processeurs de contexte de gabarit.
L’API commune ne possède pas de concept équivalent. Les données de contexte sont transmises dans un simple dict et la requête HttpRequest en cours est transmise séparément si nécessaire.
Les chargeurs de gabarits sont responsables de la découverte des gabarits, de leur chargement et du renvoi d’objets Template.
Django fournit plusieurs chargeurs de gabarits intégrés et prend en charge des chargeurs de gabarits personnalisés.
\nLes processeurs de contexte sont des fonctions qui reçoivent la requête HttpRequest en cours comme paramètre et renvoient un dict de données à ajouter au contexte de production.
Leur utilisation principale est d’ajouter dans le contexte des données fréquemment utilisées partagées par tous les gabarits, sans devoir répéter le code correspondant dans chaque vue.
\nDjango fournit un bon nombre de processeurs de contexte intégrés. Vous pouvez également implémenter vos propres processeurs de contexte.
\nLes moteurs de gabarit sont configurés dans le réglage TEMPLATES. Il s’agit d’une liste de configurations, une par moteur. La valeur par défaut est vide. Le fichier settings.py généré par la commande startproject définit une valeur plus utile :
TEMPLATES = [\n {\n "BACKEND": "django.template.backends.django.DjangoTemplates",\n "DIRS": [],\n "APP_DIRS": True,\n "OPTIONS": {\n # ... some options here ...\n },\n },\n]\nBACKEND est un chemin Python pointé vers une classe de moteur de gabarit implémentant l’API de moteur de gabarit de Django. Les moteurs intégrés sont django.template.backends.django.DjangoTemplates et django.template.backends.jinja2.Jinja2.
Comme la plupart des moteurs chargent des gabarits à partir de fichiers, la configuration de chaque moteur contient au premier niveau deux réglages courants :
\nDIRS définit une liste de répertoires dans lesquels le moteur recherche des fichiers sources de gabarits, dans l’ordre de leur recherche.
APP_DIRS indique si le moteur doit rechercher les gabarits dans les applications installées. Chaque moteur définit un nom conventionnel à attribuer au sous-répertoire des applications où ses gabarits devraient se trouver.
Même si ce n’est pas fréquent, il est possible de configurer plusieurs instances d’un même moteur avec des options différentes. Dans ce cas, il est nécessaire de définir un nom NAME unique pour chaque moteur.
OPTIONS contient des réglages spécifiques au moteur.
Le module django.template.loader définit deux fonctions pour charger des gabarits.
Cette fonction charge le gabarit ayant le nom donné et renvoie un objet Template.
Le type exact de la valeur renvoyée dépend du moteur qui a chargé le gabarit. Chaque moteur possède sa propre classe Template.
get_template() essaie avec chaque moteur de gabarit dans l’ordre jusqu’à ce que l’un d’eux réussisse. Si le gabarit n’est pas trouvé, une exception TemplateDoesNotExist est générée. Si le gabarit est trouvé mais contient une syntaxe non valable, une exception TemplateSyntaxError est générée.
La façon dont les gabarits sont recherchés et chargés dépend de chaque moteur et de sa configuration.
\nSi vous souhaitez restreindre la recherche à un moteur de gabarit particulier, passez le nom NAME du moteur dans le paramètre using.
select_template() est semblable à get_template(), sauf qu’il accepte une liste de noms de gabarits. Il essaie chaque nom dans l’ordre et renvoie le premier gabarit existant.
Si le chargement d’un gabarit échoue, les deux exceptions suivantes définies dans django.template peuvent être générées :
Cette exception est générée lorsqu’aucun gabarit n’a pu être trouvé. Elle accepte les paramètres facultatifs suivants pour remplir le gabarit postmortem sur la page de débogage :
\nbackendL’instance de moteur de gabarit dans lequel l’exception s’est produite.
\ntriedUne liste de sources qui ont été parcourues pour la recherche du gabarit. Elle se trouve sous la forme d’une liste de tuples contenant (origine, statut), où origine est un objet de type origine et statut est une chaîne contenant la raison expliquant l’absence du gabarit.
chainUne liste d’exceptions intermédiaires TemplateDoesNotExist générées durant le chargement du gabarit. Ceci est exploité par des fonctions comme get_template(), qui essaient de charger un gabarit donné depuis plusieurs moteurs.
Cette exception est générée lorsqu’un gabarit a été trouvé, mais qu’il contient des erreurs.
\nLes objets Template renvoyés par get_template() et select_template() doivent fournir une méthode render() ayant la signature suivante :
Produit ce gabarit en fonction du contexte donné.
\nSi context est fourni, il doit s’agir d’un dict. S’il n’est pas fourni, le moteur va produire le gabarit avec un contexte vide.
Si request est fourni, il doit s’agir d’un objet HttpRequest. Le moteur doit se charger ensuite de le rendre disponible, ainsi que le jeton CSRF, dans le gabarit. La manière de le faire dépend de chaque moteur.
Voici un exemple de l’algorithme de recherche. Pour cet exemple, le réglage TEMPLATES est :
TEMPLATES = [\n {\n "BACKEND": "django.template.backends.django.DjangoTemplates",\n "DIRS": [\n "/home/html/example.com",\n "/home/html/default",\n ],\n },\n {\n "BACKEND": "django.template.backends.jinja2.Jinja2",\n "DIRS": [\n "/home/html/jinja2",\n ],\n },\n]\nSi vous appelez get_template('story_detail.html'), voici les fichiers que Django va rechercher, dans l’ordre :
/home/html/example.com/story_detail.html (moteur 'django')
/home/html/default/story_detail.html (moteur 'django')
/home/html/jinja2/story_detail.html (moteur 'jinja2')
Si vous appelez select_template(['story_253_detail.html', 'story_detail.html']), voici ce que Django va rechercher :
/home/html/example.com/story_253_detail.html (moteur 'django')
/home/html/default/story_253_detail.html (moteur 'django')
/home/html/jinja2/story_253_detail.html (moteur 'jinja2')
/home/html/example.com/story_detail.html (moteur 'django')
/home/html/default/story_detail.html (moteur 'django')
/home/html/jinja2/story_detail.html (moteur 'jinja2')
Lorsque Django trouve un gabarit existant, il stoppe sa recherche.
\n\nIl est possible – et préférable – d’organiser les gabarits dans des sous-répertoires de chaque répertoire contenant des gabarits. La convention est de créer un sous-répertoire par application Django, en y ajoutant d’autres sous-répertoires au besoin.
\nCe conseil est tout à votre avantage. Le placement de tous les gabarits au niveau racine d’un seul répertoire devient rapidement ingérable.
\nPour charger un gabarit se trouvant dans un sous-répertoire, utilisez la barre oblique, comme ceci :
\nget_template("news/story_detail.html")\nToujours avec le même réglage TEMPLATES que ci-dessus, cet exemple va tenter de charger les gabarits suivants :
/home/html/example.com/news/story_detail.html (moteur 'django')
/home/html/default/news/story_detail.html (moteur 'django')
/home/html/jinja2/news/story_detail.html (moteur 'jinja2')
De plus, pour rationaliser l’aspect répétitif du chargement et de la production des gabarits, Django propose une fonction raccourci qui automatise le processus.
\nrender_to_string() charge un gabarit comme get_template() et appelle sa méthode render() immédiatement. Elle accepte les paramètres ci-après.
template_nameLe nom d’un gabarit à charger et à produire. S’il s’agit d’une liste de noms de gabarits, Django utilise select_template() au lieu de get_template() pour chercher le gabarit.
contextUn dict à utiliser comme contexte de gabarit lors de la production.
requestUn objet HttpRequest facultatif qui sera disponible durant le processus de rendu du gabarit.
usingUn nom NAME de moteur de gabarit facultatif. La recherche de gabarit sera limitée à ce moteur.
Exemple d’utilisation :
\nfrom django.template.loader import render_to_string\n\nrendered = render_to_string("my_template.html", {"foo": "bar"})\nVoir aussi le raccourci render() qui appelle render_to_string() et fournit le résultat à un objet HttpResponse prêt à être renvoyé depuis une vue.
Finalement, vous pouvez utiliser directement des moteurs configurés :
\nLes moteurs de gabarit sont disponibles dans django.template.engines:
from django.template import engines\n\ndjango_engine = engines["django"]\ntemplate = django_engine.from_string("Hello {{ name }}!")\nLa clé de recherche, 'django' dans cet exemple, correspond au réglage NAME du moteur.
Définissez BACKEND à 'django.template.backends.django.DjangoTemplates' pour configurer un moteur de gabarit de Django.
Lorsque APP_DIRS vaut True, les moteurs DjangoTemplates cherchent les gabarits dans le sous-répertoire templates des applications installées. Ce nom générique a été conservé par rétrocompatibilité.
Les moteurs DjangoTemplates acceptent les OPTIONS suivantes :
'autoescape': une valeur booléenne contrôlant si l’auto-échappement HTML est activé.
Sa valeur par défaut est True.
'context_processors': une liste de chemins Python pointés vers des objets exécutables utilisés pour remplir le contexte lorsqu’un gabarit est produit avec une requête. Ces exécutables acceptent un objet requête comme paramètre et renvoient un dictionnaire d’éléments à fusionner dans le contexte.
La valeur par défaut est une liste vide.
\nVoir RequestContext pour plus d’informations.
'debug': une valeur booléenne qui active ou désactive le mode débogage des gabarits. Quand elle vaut True, une page d’erreur élaborée affiche un rapport détaillé lors de toute exception générée durant le rendu des gabarits. Ce rapport contient les extraits concernés du gabarit avec les bonnes lignes mises en évidence.
La valeur par défaut correspond à la valeur du réglage DEBUG.
'loaders': une liste de chemins Python pointés vers des classes de chargeurs de gabarits. Chaque classe Loader sait comment importer les gabarits d’une source particulière. Il est possible d’indiquer des tuples au lieu de chaînes. Le premier élément du tuple correspond au nom de classe de Loader alors que les éléments suivants seront transmis à la classe Loader en vue de son initialisation.
La valeur par défaut dépend des valeurs de DIRS et de APP_DIRS.
Voir Types de chargeurs pour les détails.
\n'string_if_invalid': résultat, sous forme de chaîne de caractères, que le système des gabarits utilise pour remplacer le contenu de variables non valides (par ex. mal orthographiées).
La valeur par défaut est une chaîne vide.
\nVoir Traitement des variables non valides pour les détails.
\n'file_charset': le jeu de caractères utilisé pour lire les fichiers de gabarits depuis le disque.
Sa valeur par défaut est 'utf-8'.
'libraries': un dictionnaire d’étiquettes et de chemins Python pointés de modules de balises de gabarit à inscrire auprès du moteur de gabarit. Ceci peut être utilisé pour ajouter de nouvelles bibliothèques ou pour fournir des étiquettes alternatives à celles qui existent. Par exemple :
OPTIONS = {\n "libraries": {\n "myapp_tags": "path.to.myapp.tags",\n "admin.urls": "django.contrib.admin.templatetags.admin_urls",\n },\n}\nLes bibliothèques peuvent être chargées en passant la clé de dictionnaire correspondante à la balise {% load %}.
'builtins': une liste de chemins Python pointés de modules de balises de gabarit à ajouter aux modules intégrés. Par exemple :
OPTIONS = {\n "builtins": ["myapp.builtins"],\n}\nLes balises et les filtres des bibliothèques intégrées peuvent être utilisés sans devoir d’abord faire appel à la balise {% load %}.
Nécessite que Jinja2 soit installé :
\nLinux / macOS
$ python -m pip install Jinja2\nWindows
...\\> py -m pip install Jinja2\nDéfinissez BACKEND à 'django.template.backends.jinja2.Jinja2' pour configurer un moteur de gabarit Jinja2.
Lorsque APP_DIRS vaut True, les moteurs Jinja2 cherchent les gabarits dans le sous-répertoire jinja2 des applications installées.
L’élément le plus important dans OPTIONS est 'environment'. Il s’agit d’un chemin Python pointé vers un objet exécutable renvoyant un environnement Jinja2. La valeur par défaut est 'jinja2.Environment'. Django appelle cet objet et transmet d’autres options en tant que paramètres nommés. De plus, ajoute des valeurs par défaut qui diffèrent de celles de Jinja2 pour quelques-unes :
'autoescape': True
'auto_reload': settings.DEBUG
'undefined': DebugUndefined si settings.DEBUG sinon Undefined
Les moteurs Jinja2 acceptent aussi les OPTIONS suivantes :
'context_processors': une liste de chemins Python pointés vers des objets exécutables utilisés pour remplir le contexte lorsqu’un gabarit est produit avec une requête. Ces exécutables acceptent un objet requête comme paramètre et renvoient un dictionnaire d’éléments à fusionner dans le contexte.
La valeur par défaut est une liste vide.
\n\nLa configuration par défaut est volontairement limitée au minimum. Si un gabarit est produit avec une requête (par ex. en utilisant render()), le moteur Jinja2 ajoute les éléments globaux request, csrf_input et csrf_token au contexte. À part ça, ce moteur ne crée pas d’environnement adapté à Django. Il n’a pas connaissance des filtres et des balises de Django. Afin de pouvoir utiliser des API spécifiques à Django, vous devez les configurer dans l’environnement.
Par exemple, vous pouvez créer monproject/jinja2.py avec ce contenu :
from django.templatetags.static import static\nfrom django.urls import reverse\n\nfrom jinja2 import Environment\n\n\ndef environment(**options):\n env = Environment(**options)\n env.globals.update(\n {\n "static": static,\n "url": reverse,\n }\n )\n return env\net définir l’option 'environment' à 'monproject.jinja2.environment'.
Dès lors, vous pouvez utiliser les structures suivantes dans les gabarits Jinja2 :
\n<img src="{{ static('path/to/company-logo.png') }}" alt="Company Logo">\n\n<a href="{{ url('admin:index') }}">Administration</a>\nLes concepts de balises et filtres existent aussi bien dans le langage de gabarit de Django que dans Jinja2, mais ils sont utilisés différemment. Comme Jinja2 prend en charge le passage de paramètres à des objets exécutables dans les gabarits, beaucoup de fonctionnalités qui nécessitent une balise de gabarit ou un filtre dans les gabarits Django peuvent être implémentées en appelant une fonction dans les gabarits Jinja2, comme l’exemple ci-dessus le montre. L’espace de noms global de Jinja2 élimine le besoin de processeurs de contexte de gabarit. Le langage de gabarit de Django ne possède pas d’équivalent aux tests Jinja2.
\n