À moins que vous n’ayez l’intention de construire des sites Web et des applications qui ne font rien d’autre que de publier du contenu, et n’acceptant aucune saisie de la part de ses visiteurs, vous allez avoir besoin de comprendre et d’utiliser des formulaires.
\nDjango fournit un certain nombre d’outils et de bibliothèques pour vous aider à créer des formulaires de saisie pour les visiteurs du site, puis pour aider à traiter et à répondre à ces saisies.
\nEn HTML, un formulaire est un ensemble d’éléments à l’intérieur des balises <form>...</form> qui permettent à un visiteur d’effectuer des actions comme saisir du texte, sélectionner des options, manipuler des objets ou des contrôles, et ainsi de suite, puis d’envoyer ces informations au serveur.
Certains de ces éléments d’interface de formulaires - boîtes de saisie de texte ou cases à cocher - sont intégrés à HTML. D’autres éléments sont beaucoup plus complexes ; une interface qui affiche un sélecteur de date ou qui permet de déplacer un curseur ou de contrôler un autre élément graphique utilise généralement du code JavaScript et CSS, ainsi que des éléments <input> de formulaires HTML pour produire ce genre d’effets.
En plus de ses éléments <input>, un formulaire doit préciser deux choses :
où : l’URL vers laquelle les données correspondant à la saisie de l’utilisateur doivent être renvoyées
comment : la méthode HTTP utilisée pour renvoyer les données
Par exemple, le formulaire de connexion pour l’administration de Django contient plusieurs éléments <input>: un de type="text" pour le nom d’utilisateur, un de type="password" pour le mot de passe, et un de type="submit" pour le bouton « Connexion ». Il contient également des champs de texte cachés que l’utilisateur ne voit pas, mais que Django utilise pour déterminer ce qu’il faut faire après la connexion.
Il indique également au navigateur que les données du formulaire doivent être envoyées à l’URL spécifiée dans l’attribut action de la balise <form> (/admin/) et qu’elles doivent être envoyées en utilisant le mécanisme HTTP spécifié par l’attribut method (post).
Lorsque le bouton <input type="submit" value="Connexion"> est déclenché, les données sont renvoyées à /admin/.
GET et POSTLien vers cette rubrique#GET et POST sont les seules méthodes HTTP à utiliser dans les formulaires.
Le formulaire de connexion de Django est renvoyé en utilisant la méthode POST, par laquelle le navigateur regroupe les données du formulaire, les encode pour la transmission, les envoie au serveur, puis reçoit la réponse en retour.
GET, en revanche, regroupe les données fournies dans une chaîne et l’utilise pour composer une URL. L’URL contient l’adresse à laquelle les données doivent être envoyées, ainsi que les clés et les valeurs fournies. Vous pouvez en voir un exemple si vous effectuez une recherche dans la documentation de Django, car cela va produire une URL de la forme https://docs.djangoproject.com/search/?q=forms&release=1.
GET et POST sont généralement utilisées à des fins différentes.
Toute requête pouvant être utilisée pour modifier l’état du système, par exemple une requête qui applique des changements en base de données, devrait utiliser POST. GET ne devrait être employée que pour des requêtes qui n’affectent pas l’état du système.
GET ne conviendrait pas non plus pour un formulaire de changement de mot de passe, car le mot de passe apparaîtrait en clair dans l’URL ainsi que dans l’historique du navigateur et les journaux du serveur. Elle ne conviendrait pas non plus pour des données volumineuses ou pour des données binaires telles que pour une image. Une application Web utilisant des requêtes GET pour des formulaires administratifs ne serait pas sécurisée : il est facile pour un attaquant de simuler une requête de formulaire pour obtenir l’accès à des parties sensibles du système. Les requêtes POST accompagnées par d’autres protections comme la protection CSRF de Django offrent un bien meilleur contrôle sur les accès.
D’autre part, GET convient pour des interfaces comme un formulaire de recherche Web, car les URL qui représentent une requête GET peuvent être facilement conservées dans un signet, partagées ou ré-envoyées.
La gestion des formulaires est une affaire complexe. Considérez l’application d’administration de Django où de nombreuses données de différents types doivent être préparées pour être affichées dans un formulaire, produites en HTML, éditées par une interface conviviale, renvoyées vers le serveur, validées et nettoyées, et finalement enregistrées ou transmises pour traitement ultérieur.
\nLa fonctionnalité des formulaires de Django peut simplifier et automatiser de larges portions de ce travail et peut aussi le faire de manière plus sécurisée que la plupart des programmeurs ne pourraient le faire en écrivant leur propre code.
\nDjango gère trois parties distinctes du travail induit par les formulaires :
\npréparation et restructuration des données en vue de leur présentation
création des formulaires HTML pour les données
réception et traitement des formulaires et des données envoyés par le client
Il est possible d’écrire du code qui fait tout cela manuellement, mais Django peut s’en charger à votre place.
\nNous avons brièvement décrit les formulaires HTML, mais un objet HTML <form> n’est qu’un élément de la machinerie nécessaire.
Dans le contexte d’une application Web, « formulaire » peut se référer à cette balise HTML <form>, à la classe Form de Django qui la produit, aux données structurées renvoyées lorsque le formulaire est soumis, ou encore au fonctionnement de bout en bout de ces différentes parties.
Form de DjangoLien vers cette rubrique#La classe Form de Django se situe au cœur de ce système de composants. De la même façon qu’un modèle Django décrit la structure logique d’un objet, son comportement et la manière dont ses parties nous sont présentées, une classe Form décrit un formulaire et détermine son fonctionnement et son apparence.
De la même façon que les champs d’une classe de modèle correspondent à des champs de base de données, les champs d’une classe de formulaire correspondent aux éléments <input> d’un formulaire HTML (un ModelForm fait correspondre les champs d’une classe de modèle à des éléments <input> d’un formulaire HTML via un formulaire Form; cela constitue la base de l’interface d’administration de Django).
Les champs d’un formulaire sont eux-mêmes des classes ; elles gèrent les données de formulaire et s’occupent de la validation lorsque des données de formulaires sont reçues. Un champ DateField et un champ FileField gèrent des types de données très différents et doivent procéder à des actions différentes.
Un champ de formulaire est présenté dans une interface de navigateur sous forme de « composant » HTML, un élément d’interface utilisateur. Chaque type de champ contient une classe Widget appropriée par défaut, mais celles-ci peuvent être remplacées au besoin.
\nLors du rendu d’un objet Django pour son affichage, il s’agit généralement de :
\nobtenir l’élément dans la vue (le récupérer à partir de la base de données, par exemple)
le transmettre au contexte de gabarit
le transformer en balisage HTML en utilisant des variables de gabarit
L’affichage d’un formulaire dans un gabarit suit à peu près le même processus que pour tout autre type d’objet, mais il y a tout de même certaines différences notables.
\nDans le cas d’une instance de modèle ne contenant aucune donnée, il n’y aura pas beaucoup de sens d’en faire quoi que ce soit dans un gabarit. En revanche, il est totalement raisonnable de vouloir afficher un formulaire vierge, c’est ce qu’il faut faire lorsqu’on veut que quelqu’un le remplisse.
\nAinsi, lorsque nous manipulons une instance de modèle dans une vue, nous la récupérons typiquement à partir de la base de données. Lorsque nous manipulons un formulaire, nous en créons typiquement une instance dans la vue.
\nLors de la création d’une instance de formulaire, on peut choisir de le laisser vide ou de le pré-remplir, par exemple avec :
\ndes données provenant d’une instance de modèle enregistrée (comme dans le cas des formulaires d’administration pour l’édition)
des données que nous avons obtenues à partir d’autres sources
des données reçues d’un envoi de formulaire HTML
Le dernier de ces cas est le plus intéressant, car c’est ce qui permet aux utilisateurs de ne pas seulement lire un site Web, mais aussi de renvoyer des informations aux sites Web.
\nSupposons que vous vouliez créer un formulaire simple sur votre site dans le but d’obtenir le nom de l’utilisateur. Voici ce qu’il faudrait obtenir dans le navigateur :
\n<form action="/your-name/" method="post">\n <label for="your_name">Your name: </label>\n <input id="your_name" type="text" name="your_name" value="{{ current_name }}">\n <input type="submit" value="OK">\n</form>\nLe navigateur saura alors qu’il doit renvoyer les données du formulaire vers l’URL /your-name/, en utilisant la méthode POST. Il affichera un champ de texte libellé « Your name: » et un bouton intitulé « OK ». Si le contexte de gabarit contient une variable current_name, celle-ci sera utilisée pour pré-remplir le champ your_name.
Il faudra une vue qui produit le gabarit contenant le formulaire HTML et qui puisse fournir le champ current_name si nécessaire.
Lorsque le formulaire aura été envoyé, la requête POST envoyée au serveur contiendra les données du formulaire.
Mais il sera également nécessaire d’avoir une vue répondant à l’URL /your-name/ qui se chargera de trouver les paires clé-valeur dans la requête, puis de les traiter.
Il s’agit d’un formulaire très simple. En pratique, un formulaire peut contenir des dizaines ou centaines de champs, dont beaucoup peuvent être pré-remplis, et il est possible que l’utilisateur doive passer par plusieurs cycles d’envoi/édition avant que l’opération globale ne soit terminée.
\nOn peut attendre du navigateur qu’il s’occupe d’une partie de la validation, même avant que le formulaire ne soit envoyé. Peut-être que certains champs seront bien plus complexes, permettant par exemple de choisir des dates dans un calendrier.
\nCompte tenu de tout ceci, il est bien plus avantageux que Django se charge lui-même de la plupart du travail.
\nFormLien vers cette rubrique#Nous savons déjà à quoi notre formulaire HTML doit ressembler. Notre point de départ dans Django est le suivant :
\nfrom django import forms\n\nclass NameForm(forms.Form):\n your_name = forms.CharField(label='Your name', max_length=100)\nCela définit une classe Form comportant un seul champ (your_name). Nous avons attribué une étiquette conviviale à ce champ ; celle-ci apparaîtra dans la balise <label> au moment de l’affichage (bien que dans ce cas, le contenu indiqué dans label est en réalité identique à celui qui aurait été généré automatiquement si nous n’avions rien fait).
La longueur maximale du champ est définie par max_length. Cela fait deux choses : la balise HTML <input> reçoit l’attribut maxlength="100" (afin que le navigateur empêche lui-même la saisie d’un plus grand nombre de caractères), et ultérieurement lorsque Django reçoit en retour les données de formulaire, il valide que les données respectent cette longueur.
Une instance de Form possède une méthode is_valid() qui procède aux routines de validation pour tous ses champs. Lorsque la méthode est appelée et que tous les champs contiennent des données valables, celle-ci :
renvoie True;
insère les données du formulaire dans l’attribut cleaned_data.
Le formulaire complet, lorsqu’il est affiché pour la première fois, ressemble à ceci :
\n<label for="your_name">Your name: </label>\n<input id="your_name" type="text" name="your_name" maxlength="100" required>\nNotez qu’il n’inclut pas les balises <form> ni de bouton d’envoi. Ces éléments doivent être ajoutés par celui qui rédige le gabarit.
Les données de formulaire renvoyés à un site Web Django sont traitées par une vue, en principe la même qui a servi à produire le formulaire. Cela permet de réutiliser une partie de la même logique.
\nPour traiter le formulaire, nous devons en créer une instance dans la vue à destination de l’URL à laquelle il doit apparaître :
\nfrom django.http import HttpResponseRedirect\nfrom django.shortcuts import render\n\nfrom .forms import NameForm\n\ndef get_name(request):\n # if this is a POST request we need to process the form data\n if request.method == 'POST':\n # create a form instance and populate it with data from the request:\n form = NameForm(request.POST)\n # check whether it's valid:\n if form.is_valid():\n # process the data in form.cleaned_data as required\n # ...\n # redirect to a new URL:\n return HttpResponseRedirect('/thanks/')\n\n # if a GET (or any other method) we'll create a blank form\n else:\n form = NameForm()\n\n return render(request, 'name.html', {'form': form})\nSi nous arrivons dans cette vue avec une requête GET, la vue crée une instance de formulaire vierge et la place dans le contexte de gabarit en vue de son affichage. C’est à quoi l’on peut s’attendre lors du premier accès à l’URL en question.
Si le formulaire est envoyé par une requête POST, la vue crée également une instance de formulaire et la complète avec les données reçues à partir de la requête : form = NameForm(request.POST). C’est ce qu’on appelle « lier les données au formulaire » (il s’agit maintenant d’un formulaire lié, « bound » en anglais).
La méthode is_valid() est appelée ; si elle ne renvoie pas True, on se retrouve au stade du gabarit contenant le formulaire. Mais cette fois, le formulaire n’est plus vierge (non lié ou unbound) ce qui fait que le formulaire HTML sera rempli avec les données saisies précédemment, données qui peuvent être modifiées et corrigées selon les besoins.
Si is_valid() renvoie True, toutes les données validées du formulaire sont alors accessibles dans l’attribut cleaned_data. Ces données peuvent être utilisées pour mettre à jour la base de données ou effectuer d’autres opérations avant de renvoyer au navigateur une redirection HTTP lui indiquant l’URL à recharger.
Il n’y a pas grand chose à faire dans le gabarit name.html:
<form action="/your-name/" method="post">\n {% csrf_token %}\n {{ form }}\n <input type="submit" value="Submit">\n</form>\nTous les champs de formulaire et leurs attributs seront convertis en balises HTML à partir de {{ form }} par le langage de gabarit de Django.
Nous possédons maintenant un formulaire Web fonctionnel, défini par une instance Form de Django, traité par une vue et affiché sous forme de balise HTML <form>.
C’est tout ce dont vous avez besoin pour commencer, mais l’infrastructure des formulaires a beaucoup plus à vous offrir. À partir du moment où vous comprenez les bases du processus décrit ci-dessus, il est bon de connaître les autres fonctionnalités mises à disposition par le système des formulaires et d’en savoir un peu plus au sujet de la machinerie sous-jacente.
\nForm de DjangoLien vers cette rubrique#Toutes les classes de formulaires sont créées comme sous-classes de django.forms.Form ou de django.forms.ModelForm. ModelForm peut être considéré comme une sous-classe de Form. Form et ModelForm héritent effectivement de comportements communs provenant de la classe (privée) BaseForm, mais ce détail d’implémentation est rarement significatif.
La distinction entre Formulaires liés et non liés est importante :
\nUn formulaire non renseigné n’a aucune donnée associée. Lorsqu’il est présenté à l’utilisateur, il sera vide ou ne contiendra que des valeurs par défaut.
Un formulaire renseigné contient des données envoyées et il est donc possible de lui demander si ces données sont valides. Si un formulaire renseigné non valide est affiché, il peut contenir des messages d’erreur intégrés indiquant à l’utilisateur quelles sont les données à corriger.
L’attribut is_bound d’un formulaire indique si des données ont été liées au formulaire ou pas.
Voici un formulaire un peu plus utile que notre exemple minimal ci-dessus, que nous pourrions utiliser pour implémenter une fonctionnalité « Contactez-moi » sur un site Web personnel :
\nfrom django import forms\n\nclass ContactForm(forms.Form):\n subject = forms.CharField(max_length=100)\n message = forms.CharField(widget=forms.Textarea)\n sender = forms.EmailField()\n cc_myself = forms.BooleanField(required=False)\nLe formulaire précédent comportait un seul champ, your_name, de type CharField. Dans ce cas, le formulaire possède quatre champs : subject, message, sender et cc_myself. CharField, EmailField et BooleanField ne sont que trois des types de champs disponibles ; une liste complète se trouve dans Champs de formulaires.
À chaque champ de formulaire correspond une classe Widget, qui elle-même se réfère à un composant de formulaire HTML comme par exemple <input type="text">.
Dans la plupart des cas, le composant par défaut du champ convient bien. Par exemple, le composant par défaut du champ CharField est TextInput, qui produit une balise <input type="text"> en HTML. Si au contraire vous aviez souhaité une balise <textarea>, il aurait fallu définir le composant approprié lors de la définition du champ de formulaire, comme nous l’avons fait pour le champ message.
Quelles que soient les données envoyées avec un formulaire, au moment où elles ont été validées avec succès suite à l’appel de is_valid() (et que is_valid() a renvoyé True), les données de formulaire validées se trouvent dans le dictionnaire form.cleaned_data. Ces données auront été gracieusement converties en types Python pour vous.
Dans l’exemple ci-dessus du formulaire de contact, cc_myself sera une valeur booléenne. De la même manière, des champs de type IntegerField et FloatField convertissent les valeurs en types Python int et float, respectivement.
Voici comment les données de formulaire pourraient être traitées dans la vue qui gère ce formulaire :
\nfrom django.core.mail import send_mail\n\nif form.is_valid():\n subject = form.cleaned_data['subject']\n message = form.cleaned_data['message']\n sender = form.cleaned_data['sender']\n cc_myself = form.cleaned_data['cc_myself']\n\n recipients = ['info@example.com']\n if cc_myself:\n recipients.append(sender)\n\n send_mail(subject, message, sender, recipients)\n return HttpResponseRedirect('/thanks/')\nCertains types de champ ont besoin de traitement supplémentaire. Par exemple, les fichiers téléversés via un formulaire doivent être traités différemment (ils sont accessibles par request.FILES, et non pas par request.POST). Pour plus de détails sur la façon de gérer des téléversements de fichiers avec un formulaire, consultez Liaison de fichiers téléversés avec un formulaire.
Tout ce qui est nécessaire pour qu’un formulaire soit inclus dans un gabarit est de placer l’instance de formulaire dans le contexte du gabarit. Ainsi, si le formulaire est appelé form dans le contexte, {{ form }} suffira à afficher ses éléments <label> et <input> de manière appropriée.
Il existe toutefois d’autres options pour les paires <label>/<input>:
{{ form.as_table }} affiche les composants sous forme de cellules de tableau à l’intérieur de balises <tr>
{{ form.as_p }} affiche les composants dans des balises <p>
{{ form.as_ul }} affiche les composants dans des balises <li>
Notez que vous devrez ajouter vous-même les éléments <table> ou <ul> autour du contenu produit.
Voici ce qu’affiche {{ form.as_p }} pour notre instance de ContactForm:
<p><label for="id_subject">Subject:</label>\n <input id="id_subject" type="text" name="subject" maxlength="100" required></p>\n<p><label for="id_message">Message:</label>\n <textarea name="message" id="id_message" required></textarea></p>\n<p><label for="id_sender">Sender:</label>\n <input type="email" name="sender" id="id_sender" required></p>\n<p><label for="id_cc_myself">Cc myself:</label>\n <input type="checkbox" name="cc_myself" id="id_cc_myself"></p>\nNotez que chaque champ de formulaire reçoit un attribut ID défini à id_<nom-de-champ> qui est référencé par la balise label correspondante. C’est important pour garantir que les formulaires sont accessibles aux aides techniques du genre logiciel de lecture d’écran. Vous pouvez aussi personnaliser la façon dont les éléments label et id sont générés.
Voir Affichage des formulaires en HTML pour plus d’informations à ce sujet.
\nLaisser Django afficher un à un les champs du formulaire n’est pas la seule possibilité ; on peut tout à fait afficher soi-même les champs (par exemple pour changer leur ordre d’apparition). Chaque champ est accessible en tant qu’attribut du formulaire avec la syntaxe {{ form.nom_du_champ }}, ce qui, dans un gabarit Django, produira son affichage de manière appropriée. Par exemple :
{{ form.non_field_errors }}\n<div class="fieldWrapper">\n {{ form.subject.errors }}\n <label for="{{ form.subject.id_for_label }}">Email subject:</label>\n {{ form.subject }}\n</div>\n<div class="fieldWrapper">\n {{ form.message.errors }}\n <label for="{{ form.message.id_for_label }}">Your message:</label>\n {{ form.message }}\n</div>\n<div class="fieldWrapper">\n {{ form.sender.errors }}\n <label for="{{ form.sender.id_for_label }}">Your email address:</label>\n {{ form.sender }}\n</div>\n<div class="fieldWrapper">\n {{ form.cc_myself.errors }}\n <label for="{{ form.cc_myself.id_for_label }}">CC yourself?</label>\n {{ form.cc_myself }}\n</div>\nUne balise <label> complète peut aussi être générée au moyen de label_tag(). Par exemple :
<div class="fieldWrapper">\n {{ form.subject.errors }}\n {{ form.subject.label_tag }}\n {{ form.subject }}\n</div>\nLe prix de cette flexibilité est un effort un peu plus grand. Jusqu’à ce stade, nous n’avions pas à nous préoccuper de l’affichage des erreurs du formulaire, car cela se faisait automatiquement. Dans cet exemple, il a fallu s’assurer que les erreurs de chaque champ et les erreurs globales du formulaire soient effectivement affichées. Remarquez {{ form.non_field_errors }} au sommet du formulaire ainsi que l’expression de gabarit concernant les erreurs de chaque champ.
La syntaxe {{ form.nom_du_champ.errors }} affiche une liste des erreurs du formulaire, sous forme de liste non ordonnée. Cela pourrait ressembler à ceci :
<ul class="errorlist">\n <li>Sender is required.</li>\n</ul>\nLa liste possède une classe CSS errorlist pour vous permettre de mettre en forme son apparence. Si vous souhaitez personnaliser davantage l’affichage des erreurs, vous pouvez le faire par une boucle :
{% if form.subject.errors %}\n <ol>\n {% for error in form.subject.errors %}\n <li><strong>{{ error|escape }}</strong></li>\n {% endfor %}\n </ol>\n{% endif %}\nLes erreurs non liées à un champ (ou les erreurs de champs cachés qui sont affichées au sommet du formulaire lorsqu’on utilise des utilitaires comme form.as_p()) seront dotées d’une classe supplémentaire nonfield pour aider à faire la distinction avec les erreurs spécifiques à un champ. Par exemple, {{ form.non_field_errors }} ressemblerait à :
<ul class="errorlist nonfield">\n <li>Generic validation error</li>\n</ul>\nVoir L’API des formulaires pour plus de détails sur les erreurs, la mise en forme et la manipulation des attributs de formulaire dans les gabarits.
\nSi vous utilisez le même code HTML pour tous vos champs de formulaire, vous pouvez réduire la duplication de code en effectuant une boucle sur chaque champ en utilisant l’opérateur {% for %}:
{% for field in form %}\n <div class="fieldWrapper">\n {{ field.errors }}\n {{ field.label_tag }} {{ field }}\n {% if field.help_text %}\n <p class="help">{{ field.help_text|safe }}</p>\n {% endif %}\n </div>\n{% endfor %}\nVoici quelques attributs de champ utiles :
\n{{ field.label }}L’étiquette du champ, par exemple Adresse de courriel.
{{ field.label_tag }}L’intitulé du champ placé dans la balise HTML <label> appropriée. Cela comprend le paramètre label_suffix du formulaire. Par exemple, la valeur label_suffix par défaut est un caractère deux-points :
<label for="id_email">Email address:</label>\n{{ field.id_for_label }}L’attribut id utilisé pour ce champ (id_email dans l’exemple ci-dessus). Si vous construisez vous-même l’étiquette du champ, il peut être avantageux d’utiliser ceci à la place de label_tag. C’est aussi utile par exemple si vous avez du code JavaScript en ligne et que vous vouliez éviter de figer l’identifiant du champ.
{{ field.value }}La valeur du champ, par exemple quelqu-un@example.com.
{{ field.html_name }}Le nom du champ tel qu’il sera utilisé dans le nom de champ de la balise input. Il prend en compte le préfixe de formulaire, si celui-ci est défini.
{{ field.help_text }}Tout texte d’aide associé au champ.
\n{{ field.errors }}Affiche une liste <ul class="errorlist"> contenant toute erreur de validation correspondant à ce champ. Vous pouvez personnaliser la présentation des erreurs avec une boucle {% for error in field.errors %}. Dans ce cas, chaque objet de la boucle est une chaîne de caractères contenant le message d’erreur.
{{ field.is_hidden }}Cet attribut vaut True si le champ de formulaire est un champ masqué, sinon il vaut False. Ce n’est pas particulièrement utile comme variable de gabarit, mais pourrait être utile dans des tests conditionnels tels que :
{% if field.is_hidden %}\n {# Do something special #}\n{% endif %}\n{{ field.field }}L’instance Field de la classe de formulaire que cet objet BoundField adapte. Vous pouvez l’utiliser pour accéder aux attributs de Field, par exemple {{ char_field.field.max_length }}.
Si votre site utilise la même logique d’affichage des formulaires à plusieurs endroits, vous pouvez réduire la duplication en enregistrant la boucle de formulaire dans un gabarit autonome et en employant la balise include afin de réutiliser ce contenu dans d’autres gabarits :
# In your form template:\n{% include "form_snippet.html" %}\n\n# In form_snippet.html:\n{% for field in form %}\n <div class="fieldWrapper">\n {{ field.errors }}\n {{ field.label_tag }} {{ field }}\n </div>\n{% endfor %}\nSi l’objet formulaire transmis au gabarit possède un nom différent dans le contexte, vous pouvez lui donner un alias en utilisant le paramètre with de la balise include:
{% include "form_snippet.html" with form=comment_form %}\nSi vous constatez que vous reproduisez souvent ce même code, il vous faut peut-être envisager la création d’une balise d’inclusion personnalisée.
\nCette page aborde les généralités, mais les formulaires peuvent faire bien d’autres choses encore :
\nMedia)\n