{"title":"Gabarits","version":"1.10","locale":"fr","docname":"topics/templates","url":"/fr/1.10/topics/templates/","canonical":"https://djangodocs.dev/fr/1.10/topics/templates/","summary":"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…","html":"

GabaritsLien vers cette rubrique#

\n

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.

\n

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.

\n

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.

\n

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.

\n

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.

\n
\n

Prise en charge des moteurs de gabaritLien vers cette rubrique#

\n
\n

ConfigurationLien vers cette rubrique#

\n

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 :

\n
Code
TEMPLATES = [\n    {\n        'BACKEND': 'django.template.backends.django.DjangoTemplates',\n        'DIRS': [],\n        'APP_DIRS': True,\n        'OPTIONS': {\n            # ... some options here ...\n        },\n    },\n]\n
\n

BACKEND est un chemin Python pointé vers ue 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.

\n

Comme la plupart des moteurs chargent des gabarits à partir de fichiers, la configuration de chaque moteur contient au premier niveau deux réglages courants :

\n\n

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.

\n

OPTIONS contient des réglages spécifiques au moteur.

\n
\n
\n

UtilisationLien vers cette rubrique#

\n

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

\n
\n
\nget_template(template_name, using=None)Lien vers cette définition#
\n

Cette fonction charge le gabarit ayant le nom donné et renvoie un objet Template.

\n

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.

\n

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.

\n

La façon dont les gabarits sont recherchés et chargés dépend de chaque moteur et de sa configuration.

\n

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

\n
\n\n
\n
\nselect_template(template_name_list, using=None)Lien vers cette définition#
\n

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.

\n
\n\n

Si le chargement d’un gabarit échoue, les deux exceptions suivantes définies dans django.template peuvent être générées :

\n
\n
\nexception TemplateDoesNotExist(msg, tried=None, backend=None, chain=None)Lien vers cette définition#
\n

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 :

\n
\n
backend

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

\n
\n
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.

\n
\n
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.

\n
\n
\n\n
\n\n
\n
\nexception TemplateSyntaxError(msg)Lien vers cette définition#
\n

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

\n
\n\n

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

\n
\n
\nTemplate.render(context=None, request=None)Lien vers cette définition#
\n

Produit ce gabarit en fonction du contexte donné.

\n

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.

\n

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.

\n
\n\n

Voici un exemple de l’algorithme de recherche. Pour cet exemple, le réglage TEMPLATES est :

\n
Code
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]\n
\n

Si vous appelez get_template('story_detail.html'), voici les fichiers que Django va rechercher, dans l’ordre :

\n\n

Si vous appelez select_template(['story_253_detail.html', 'story_detail.html']), voici ce que Django va rechercher :

\n\n

Lorsque Django trouve un gabarit existant, il stoppe sa recherche.

\n\n

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.

\n

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

\n

Pour charger un gabarit se trouvant dans un sous-répertoire, il suffit d’utiliser la barre oblique, comme ceci :

\n
Code
get_template('news/story_detail.html')\n
\n

Toujours avec le même réglage TEMPLATES que ci-dessus, cet exemple va tenter de charger les gabarits suivants :

\n\n

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.

\n
\n
\nrender_to_string(template_name, context=None, request=None, using=None)Lien vers cette définition#
\n

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.

\n
\n
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.

\n
\n
context

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

\n
\n
request

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

\n
\n
using

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

\n
\n
\n

Exemple d’utilisation :

\n
Code
from django.template.loader import render_to_string\nrendered = render_to_string('my_template.html', {'foo': 'bar'})\n
\n
\n\n

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.

\n

Finalement, vous pouvez utiliser directement des moteurs configurés :

\n
\n
\nenginesLien vers cette définition#
\n

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

\n
Code
from django.template import engines\n\ndjango_engine = engines['django']\ntemplate = django_engine.from_string("Hello {{ name }}!")\n
\n

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

\n
\n\n
\n
\n

Moteurs intégrésLien vers cette rubrique#

\n
\n
\nclass DjangoTemplatesLien vers cette définition#
\n
\n\n

Définissez BACKEND à 'django.template.backends.django.DjangoTemplates' pour configurer un moteur de gabarit de Django.

\n

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

\n

Les moteurs DjangoTemplates acceptent les OPTIONS suivantes :

\n\n\n
\n
\nclass Jinja2Lien vers cette définition#
\n
\n\n

Nécessite que Jinja2 soit installé :

\n
Shell
$ pip install Jinja2\n
\n

Définissez BACKEND à 'django.template.backends.jinja2.Jinja2' pour configurer un moteur de gabarit Jinja2.

\n

Lorsque APP_DIRS vaut True, les moteurs Jinja2 cherchent les gabarits dans le sous-répertoire jinja2 des applications installées.

\n

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 :

\n\n

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 processeurs de contexte, des filtres et des balises de Django. Afin de pouvoir utiliser des API spécifiques à Django, vous devez les configurer dans l’environnement.

\n

Par exemple, vous pouvez créer monproject/jinja2.py avec ce contenu :

\n
Code
from __future__ import absolute_import  # Python 2 only\n\nfrom django.contrib.staticfiles.storage import staticfiles_storage\nfrom django.urls import reverse\n\nfrom jinja2 import Environment\n\n\ndef environment(**options):\n    env = Environment(**options)\n    env.globals.update({\n        'static': staticfiles_storage.url,\n        'url': reverse,\n    })\n    return env\n
\n

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

\n

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

\n
Html Jinja
<img src="{{ static('path/to/company-logo.png') }}" alt="Company Logo">\n\n<a href="{{ url('admin:index') }}">Administration</a>\n
\n

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 simplement 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
\n
\n

Moteurs personnalisésLien vers cette rubrique#

\n

Voici comment implémenter un moteur de gabarit personnalisé afin d’utiliser un autre système de gabarits. Un moteur de gabarit est une classe qui hérite de django.template.backends.base.BaseEngine. Elle doit implémenter get_template()` et, facultativement, from_string(). Voici un exemple d’une bibliothèque de gabarit fictive foobar:

\n
Code
from django.template import TemplateDoesNotExist, TemplateSyntaxError\nfrom django.template.backends.base import BaseEngine\nfrom django.template.backends.utils import csrf_input_lazy, csrf_token_lazy\n\nimport foobar\n\n\nclass FooBar(BaseEngine):\n\n    # Name of the subdirectory containing the templates for this engine\n    # inside an installed application.\n    app_dirname = 'foobar'\n\n    def __init__(self, params):\n        params = params.copy()\n        options = params.pop('OPTIONS').copy()\n        super(FooBar, self).__init__(params)\n\n        self.engine = foobar.Engine(**options)\n\n    def from_string(self, template_code):\n        try:\n          return Template(self.engine.from_string(template_code))\n        except foobar.TemplateCompilationFailed as exc:\n            raise TemplateSyntaxError(exc.args)\n\n    def get_template(self, template_name):\n        try:\n            return Template(self.engine.get_template(template_name))\n        except foobar.TemplateNotFound as exc:\n            raise TemplateDoesNotExist(exc.args, backend=self)\n        except foobar.TemplateCompilationFailed as exc:\n            raise TemplateSyntaxError(exc.args)\n\n\nclass Template(object):\n\n    def __init__(self, template):\n        self.template = template\n\n    def render(self, context=None, request=None):\n        if context is None:\n            context = {}\n        if request is not None:\n            context['request'] = request\n            context['csrf_input'] = csrf_input_lazy(request)\n            context['csrf_token'] = csrf_token_lazy(request)\n        return self.template.render(context)\n
\n

Voir DEP 182 pour plus d’informations.

\n
\n
\n

Intégration du débogage pour les moteurs personnalisésLien vers cette rubrique#

\n\n

La page de débogage de Django présente des points d’entrée pour fournir des informations détaillées lorsqu’une erreur de gabarit se produit. Les moteurs de gabarit personnalisés peuvent utiliser ces points d’entrée pour améliorer les informations d’erreur qui sont présentées aux utilisateurs. Les points d’entrée suivants sont disponibles :

\n
\n

Gabarit postmortemLien vers cette rubrique#

\n

Le gabarit postmortem apparaît lorsque TemplateDoesNotExist est générée. Il présente la liste des moteurs et chargeurs de gabarit utilisés lors de la recherche du gabarit concerné. Par exemple, si deux moteurs Django sont configurés, le gabarit postmortem ressemble à ceci :

\n\"/fr/1.10/_images/postmortem.png\"\n

Les moteurs personnalisés peuvent remplir le gabarit postmortem en passant les paramètres backend et tried lors de la génération de TemplateDoesNotExist. Les moteurs qui utilisent le gabarit postmortem doivent indiquer une origine sur l’objet de gabarit.

\n
\n
\n

Information de ligne contextuelleLien vers cette rubrique#

\n

Si une erreur se produit pendant l’analyse et le rendu d’un gabarit, Django peut afficher la ligne à laquelle s’est produite l’erreur. Par exemple :

\n\"/fr/1.10/_images/template-lines.png\"\n

Les moteurs personnalisés peuvent fournir cette information en définissant un attribut template_debug sur les exceptions générées pendant l’analyse et le rendu. Cet attribut est un dict possédant les valeurs suivantes :

\n
    \n

  • 'name': le nom du gabarit dans lequel l’exception s’est produite.

    • \n

  • 'message': le message de l’exception.

    • \n

  • 'source_lines': les lignes précédentes, suivantes ainsi que la ligne elle-même où s’est produite l’exception. C’est pour fournir du contexte, il ne faut donc pas inclure plus d’une vingtaine de lignes.

    • \n

  • 'line': le numéro de ligne à laquelle s’est produite l’exception.

    • \n

  • 'before': le contenu de la ligne ayant provoqué l’erreur, avant le symbole qui a produit l’erreur.

    • \n

  • 'during': le symbole qui a généré l’erreur.

    • \n

  • 'after': le contenu de la ligne ayant provoqué l’erreur, après le symbole qui a produit l’erreur.

    • \n

  • 'total': le nombre de lignes dans source_lines.

    • \n

  • 'top': le numéro de ligne où source_lines commence.

    • \n

  • 'bottom': le numéro de ligne où source_lines se termine.

    • \n
\n

Étant donné l’erreur de gabarit ci-dessus, template_debug ressemblerait à ceci :

\n
Code
{\n    'name': '/path/to/template.html',\n    'message': "Invalid block tag: 'syntax'",\n    'source_lines': [\n        (1, 'some\\n'),\n        (2, 'lines\\n'),\n        (3, 'before\\n'),\n        (4, 'Hello {% syntax error %} {{ world }}\\n'),\n        (5, 'some\\n'),\n        (6, 'lines\\n'),\n        (7, 'after\\n'),\n        (8, ''),\n    ],\n    'line': 4,\n    'before': 'Hello ',\n    'during': '{% syntax error %}',\n    'after': ' {{ world }}\\n',\n    'total': 9,\n    'bottom': 9,\n    'top': 1,\n}\n
\n
\n
\n

API d’origine et intégration tierceLien vers cette rubrique#

\n

Les gabarits Django possèdent un objet Origin accessible par leur attribut template.origin. Ceci permet aux informations de débogage d’apparaître dans le gabarit postmortem, de même que dans des bibliothèques tierces, telle que Django Debug Toolbar.

\n

Les moteurs personnalisés peuvent fournir leurs propres informations template.origin en créant un objet qui définit les attributs suivants :

\n
    \n

  • 'name': le chemin complet vers le gabarit.

    • \n

  • 'template_name': le chemin relatif vers le gabarit tel que transmis aux méthodes de chargement de gabarits.

    • \n

  • 'loader_name': une chaîne facultative identifiant la fonction ou la classe utilisée pour charger le gabarit, par exemple django.template.loaders.filesystem.Loader.

    • \n
\n
\n
\n
\n
\n

Le langage de gabarit de DjangoLien vers cette rubrique#

\n
\n

SyntaxeLien vers cette rubrique#

\n\n

Un gabarit Django est un simple 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.

\n

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.

\n

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

\n
\n

VariablesLien vers cette rubrique#

\n

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

\n

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

\n
Django template
My first name is {{ first_name }}. My last name is {{ last_name }}.\n
\n

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

\n
Django template
My first name is John. My last name is Doe.\n
\n

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

\n
Django template
{{ my_dict.key }}\n{{ my_object.attribute }}\n{{ my_list.0 }}\n
\n

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.

\n
\n
\n

BalisesLien vers cette rubrique#

\n

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

\n

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.

\n

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

\n
Django template
{% csrf_token %}\n
\n

La plupart des balises acceptent des paramètres :

\n
Django template
{% cycle 'odd' 'even' %}\n
\n

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

\n
Django template
{% if user.is_authenticated %}Hello, {{ user.username }}.{% endif %}\n
\n

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

\n
\n
\n

FiltresLien vers cette rubrique#

\n

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

\n

Ils ressemblent à ceci :

\n
Django template
{{ django|title }}\n
\n

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

\n
Django template
The Web Framework For Perfectionists With Deadlines\n
\n

Certains filtres acceptent un paramètre :

\n
Django template
{{ my_date|date:"Y-m-d" }}\n
\n

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

\n
\n
\n

CommentairesLien vers cette rubrique#

\n

Les commentaires ressemblent à ceci :

\n
Django template
{# this won't be rendered #}\n
\n

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

\n
\n
\n
\n

ComposantsLien vers cette rubrique#

\n\n
\n

MoteurLien vers cette rubrique#

\n

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.

\n

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.

\n
\n
\n

GabaritLien vers cette rubrique#

\n

django.template.Template représente un gabarit compilé. Les gabarits sont obtenus par Engine.get_template() ou Engine.from_string()

\n

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.

\n
\n
\n

ContexteLien vers cette rubrique#

\n

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.

\n

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.

\n

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.

\n
\n
\n

ChargeursLien vers cette rubrique#

\n

Les chargeurs de gabarits sont responsables de la découverte des gabarits, de leur chargement et du renvoi d’objets Template.

\n

Django fournit plusieurs chargeurs de gabarits intégrés et prend en charge des chargeurs de gabarits personnalisés.

\n
\n
\n

Processeurs de contexteLien vers cette rubrique#

\n

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.

\n

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.

\n

Django fournit un bon nombre de processeurs de contexte intégrés. L’implémentation d’un processeur de contexte personnalisé est aussi simple que de définir une fonction.

\n
\n
\n
","rootId":"module-django.template","toc":[{"title":"Prise en charge des moteurs de gabarit","anchor":"support-for-template-engines","children":[{"title":"Configuration","anchor":"configuration","children":[]},{"title":"Utilisation","anchor":"usage","children":[]},{"title":"Moteurs intégrés","anchor":"module-django.template.backends.django","children":[]},{"title":"Moteurs personnalisés","anchor":"custom-backends","children":[]},{"title":"Intégration du débogage pour les moteurs personnalisés","anchor":"debug-integration-for-custom-engines","children":[{"title":"Gabarit postmortem","anchor":"template-postmortem","children":[]},{"title":"Information de ligne contextuelle","anchor":"contextual-line-information","children":[]},{"title":"API d’origine et intégration tierce","anchor":"origin-api-and-3rd-party-integration","children":[]}]}]},{"title":"Le langage de gabarit de Django","anchor":"the-django-template-language","children":[{"title":"Syntaxe","anchor":"syntax","children":[{"title":"Variables","anchor":"variables","children":[]},{"title":"Balises","anchor":"tags","children":[]},{"title":"Filtres","anchor":"filters","children":[]},{"title":"Commentaires","anchor":"comments","children":[]}]},{"title":"Composants","anchor":"components","children":[{"title":"Moteur","anchor":"engine","children":[]},{"title":"Gabarit","anchor":"template","children":[]},{"title":"Contexte","anchor":"context","children":[]},{"title":"Chargeurs","anchor":"loaders","children":[]},{"title":"Processeurs de contexte","anchor":"context-processors","children":[]}]}]}],"breadcrumbs":[{"docname":"topics/index","title":"Utilisation de Django","url":"/fr/1.10/topics/"}],"prev":{"docname":"topics/forms/media","title":"Fichiers annexes de formulaire (classe Media)","url":"/fr/1.10/topics/forms/media/"},"next":{"docname":"topics/class-based-views/index","title":"Vues fondées sur les classes","url":"/fr/1.10/topics/class-based-views/"},"formats":{"html":"/fr/1.10/topics/templates/","markdown":"/fr/1.10/topics/templates.md","json":"/fr/1.10/topics/templates.json"},"source":"https://github.com/django/django/blob/stable/1.10.x/docs/topics/templates.txt","official":"https://docs.djangoproject.com/fr/1.10/topics/templates/","inVersions":["6.1","6.0","5.2","5.1","5.0","4.2","4.1","4.0","3.2","3.1","3.0","2.2","2.1","2.0","1.11","1.10","1.9"],"inLocales":["en","fr","ja","id","pt-br","es","el","pl"]}