# Documentation Django 3.1.9.dev

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

  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)

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

  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)

  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.

Astuce

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)

  `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`

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`

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.