Gabarits

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.

Un 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é.

Django 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.

Le 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.

Pour 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.

Avertissement

Le système des gabarits n’est pas protégé contre les rédacteurs de gabarits non fiables. Par exemple, un site ne devrait pas permettre à ses utilisateurs d’écrire leurs propres gabarits, car les gabarits permettent d’effectuer des actions telles que des attaques XSS et d’accéder à des propriétés de variables de gabarits qui peuvent contenir des informations sensibles.

Le langage de gabarit de Django

Syntaxe

À propos de cette section

Il s’agit ici d’un aperçu de la syntaxe du langage de gabarit de Django. Pour plus de détails, voir la référence de la syntaxe du langage.

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.

Un 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.

La syntaxe du langage de gabarit de Django implique quatre structures.

Variables

Une variable affiche une valeur à partir du contexte, qui est un objet de type dictionnaire faisant correspondre des clés à des valeurs.

Les variables sont entourées par {{ et }} comme ceci :

My first name is {{ first_name }}. My last name is {{ last_name }}.

Avec un contexte {'first_name': 'John', 'last_name': 'Doe'}, ce gabarit produit :

My first name is John. My last name is Doe.

La consultation de dictionnaire, d’attribut et d’indice de liste est implémentée par une notation pointée :

{{ my_dict.key }}
{{ my_object.attribute }}
{{ my_list.0 }}

Si 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.

Balises

Les balises permettent d’appliquer une logique arbitraire dans le processus de rendu.

Cette définition est volontairement vague. Par exemple, une balise peut produire du contenu, servir de structure de contrôle telle qu’une instruction « if » ou une boucle « for », extraire du contenu d’une base de données ou même de donner accès à d’autres balises de gabarit.

Les balises sont entourées par {% et %}, comme ceci :

{% csrf_token %}

La plupart des balises acceptent des paramètres :

{% cycle 'odd' 'even' %}

Certaines balises exigent des balises d’introduction et de terminaison :

{% if user.is_authenticated %}Hello, {{ user.username }}.{% endif %}

Une référence des balises intégrés est disponible tout comme des instructions pour écrire des balises personnalisées.

Filtres

Les filtres transforment les valeurs de variables et les paramètres de balises.

Ils ressemblent à ceci :

{{ django|title }}

Avec un contexte {'django': 'the web framework for perfectionists with deadlines'}, ce gabarit produit le résultat suivant :

The Web Framework For Perfectionists With Deadlines

Certains filtres acceptent un paramètre :

{{ my_date|date:"Y-m-d" }}

Une référence des filtres intégrés est disponible tout comme des instructions pour écrire des filtres personnalisés.

Commentaires

Les commentaires ressemblent à ceci :

{# this won't be rendered #}

Une balise {% comment %} autorise des commentaires sur plusieurs lignes.

Composants

À propos de cette section

Il s’agit ici d’un aperçu des API du langage de gabarit de Django. Pour plus de détails, voir la référence des API.

Moteur

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.

Gabarit

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.

Contexte

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.

Chargeurs

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.

Processeurs de contexte

Les 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.

Django fournit un bon nombre de processeurs de contexte intégrés. Vous pouvez également implémenter vos propres processeurs de contexte.

Prise en charge des moteurs de gabarit

Configuration

Les 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 = [
    {
        "BACKEND": "django.template.backends.django.DjangoTemplates",
        "DIRS": [],
        "APP_DIRS": True,
        "OPTIONS": {
            # ... some options here ...
        },
    },
]

BACKEND 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 :

  • DIRS 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.

Utilisation

Le module django.template.loader définit deux fonctions pour charger des gabarits.

get_template(template_name, using=None)[source]

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.

Si vous souhaitez restreindre la recherche à un moteur de gabarit particulier, passez le nom NAME du moteur dans le paramètre using.

select_template(template_name_list, using=None)[source]

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 :

exception TemplateDoesNotExist(msg, tried=None, backend=None, chain=None)[source]

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 :

backend

L’instance de moteur de gabarit dans lequel l’exception s’est produite.

tried

Une 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.

chain

Une 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.

exception TemplateSyntaxError(msg)[source]

Cette exception est générée lorsqu’un gabarit a été trouvé, mais qu’il contient des erreurs.

Les objets Template renvoyés par get_template() et select_template() doivent fournir une méthode render() ayant la signature suivante :

Template.render(context=None, request=None)

Produit ce gabarit en fonction du contexte donné.

Si 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 = [
    {
        "BACKEND": "django.template.backends.django.DjangoTemplates",
        "DIRS": [
            "/home/html/example.com",
            "/home/html/default",
        ],
    },
    {
        "BACKEND": "django.template.backends.jinja2.Jinja2",
        "DIRS": [
            "/home/html/jinja2",
        ],
    },
]

Si 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.

Utilisez django.template.loader.select_template() pour plus de souplesse

Vous pouvez utiliser select_template() pour une sélection agile des gabarits. Par exemple, si vous avez rédigé un article et que vous voulez pouvoir utiliser des gabarits spécifiques pour certains articles, utilisez quelque chose comme select_template(['story_%s_detail.html' % story.id, 'story_detail.html']). Cela vous permet d’utiliser un gabarit adapté à un article individuel, tout en se rabattant sur un gabarit standard pour les articles sans gabarit dédié.

Il 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.

Ce conseil est tout à votre avantage. Le placement de tous les gabarits au niveau racine d’un seul répertoire devient rapidement ingérable.

Pour charger un gabarit se trouvant dans un sous-répertoire, utilisez la barre oblique, comme ceci :

get_template("news/story_detail.html")

Toujours 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.

render_to_string(template_name, context=None, request=None, using=None)[source]

render_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_name

Le 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.

context

Un dict à utiliser comme contexte de gabarit lors de la production.

request

Un objet HttpRequest facultatif qui sera disponible durant le processus de rendu du gabarit.

using

Un nom NAME de moteur de gabarit facultatif. La recherche de gabarit sera limitée à ce moteur.

Exemple d’utilisation :

from django.template.loader import render_to_string

rendered = render_to_string("my_template.html", {"foo": "bar"})

Voir 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 :

engines

Les moteurs de gabarit sont disponibles dans django.template.engines:

from django.template import engines

django_engine = engines["django"]
template = django_engine.from_string("Hello {{ name }}!")

La clé de recherche, 'django' dans cet exemple, correspond au réglage NAME du moteur.

Moteurs intégrés

class DjangoTemplates[source]

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.

    Avertissement

    Ne la mettez à False que si vous produisez des gabarits non HTML !

  • '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.

    Voir 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.

  • '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.

    Voir Traitement des variables non valides pour les détails.

  • '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 = {
    "libraries": {
        "myapp_tags": "path.to.myapp.tags",
        "admin.urls": "django.contrib.admin.templatetags.admin_urls",
    },
}

    Les 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 = {
    "builtins": ["myapp.builtins"],
}

    Les balises et les filtres des bibliothèques intégrées peuvent être utilisés sans devoir d’abord faire appel à la balise {% load %}.

class Jinja2[source]

Nécessite que Jinja2 soit installé :

$ python -m pip install Jinja2

...\> py -m pip install Jinja2

Dé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

  • 'loader': un chargeur configuré pour DIRS et APP_DIRS

  • '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.

    L’utilisation de processeurs de contexte avec les gabarits Jinja2 est déconseillée.

    Les processeurs de contexte sont utiles avec les gabarits Django car ceux-ci ne permettent pas d’appeler des fonctions avec paramètres. Comme Jinja2 ne connaît pas cette restriction, il est recommandé de placer la fonction qui aurait été utilisée dans un processeur de contexte dans les variables globales à disposition du gabarit en utilisant jinja2.Environment, comme décrit ci-dessous. Vous pouvez alors appeler cette fonction dans le gabarit :

    {{ function(request) }}

    Certains processeurs de contexte des gabarits Django renvoient une valeur fixe. Pour les gabarits Jinja2, ce niveau d’indirection n’est pas nécessaire car il est possible d’ajouter des constantes directement dans jinja2.Environment.

    Le cas d’utilisation original pour l’ajout de processeurs de contexte avec Jinja2 impliquait :

    • La réalisation de calculs intensifs dépendant de la requête.

    • La disponibilité du résultat dans chaque gabarit.

    • L’utilisation du résultat plusieurs fois dans chaque gabarit.

    Tant que toutes ces conditions ne sont pas respectées, il est plus en accord avec les concepts de Jinja2 de passer une fonction au gabarit.

La 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
from django.urls import reverse

from jinja2 import Environment


def environment(**options):
    env = Environment(**options)
    env.globals.update(
        {
            "static": static,
            "url": reverse,
        }
    )
    return env

et définir l’option 'environment' à 'monproject.jinja2.environment'.

Dès lors, vous pouvez utiliser les structures suivantes dans les gabarits Jinja2 :

<img src="{{ static('path/to/company-logo.png') }}" alt="Company Logo">

<a href="{{ url('admin:index') }}">Administration</a>

Les 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.

Back to Top