Om du inte planerar att bygga webbplatser och applikationer som inte gör något annat än att publicera innehåll och inte accepterar inmatning från dina besökare, kommer du att behöva förstå och använda formulär.
\nDjango tillhandahåller en rad verktyg och bibliotek som hjälper dig att bygga formulär för att acceptera inmatning från webbplatsbesökare och sedan bearbeta och svara på inmatningen.
\nI HTML är ett formulär en samling element inuti .<form>.</form>. som gör det möjligt för en besökare att göra saker som att skriva in text, välja alternativ, manipulera objekt eller kontroller och så vidare, och sedan skicka tillbaka informationen till servern.
Vissa av dessa formulärgränssnittselement - textinmatning eller kryssrutor - är inbyggda i själva HTML. Andra är mycket mer komplexa; ett gränssnitt som visar en datumväljare eller låter dig flytta ett skjutreglage eller manipulera kontroller använder vanligtvis JavaScript och CSS samt HTML-formulär <input> element för att uppnå dessa effekter.
Förutom dess <input>-element måste ett formulär ange två saker:
där: den URL till vilken de data som motsvarar användarens inmatning ska returneras
how: den HTTP-metod som data ska returneras med
Som ett exempel innehåller inloggningsformuläret för Django-administratören flera <input>-element: ett av type="text" för användarnamnet, ett av type="password" för lösenordet och ett av type="submit" för knappen ”Logga in”. Det innehåller också några dolda textfält som användaren inte ser, som Django använder för att avgöra vad som ska göras härnäst.
Den talar också om för webbläsaren att formulärdata ska skickas till den URL som anges i <form> action attribut - /admin/ - och att det ska skickas med hjälp av HTTP-mekanismen som anges av method attribut - post.
När elementet <input type="submit" value="Log in"> utlöses, returneras data till /admin/.
GET och POSTLink to this heading#GET och POST är de enda HTTP-metoder som ska användas när man hanterar formulär.
Djangos inloggningsformulär returneras med hjälp av metoden POST, där webbläsaren buntar ihop formulärdata, kodar den för överföring, skickar den till servern och sedan får tillbaka svaret.
GET samlar däremot de data som skickas i en sträng och använder denna för att skapa en URL. URL:en innehåller adressen dit data ska skickas, samt datanycklar och värden. Du kan se detta i aktion om du gör en sökning i Django-dokumentationen, som kommer att producera en URL av formen https://docs.djangoproject.com/search/?q=forms&release=1.
GET och POST används vanligtvis för olika ändamål.
Alla förfrågningar som kan användas för att ändra systemets tillstånd - t.ex. en förfrågan som gör ändringar i databasen - bör använda POST. GET bör endast användas för förfrågningar som inte påverkar systemets tillstånd.
GET skulle också vara olämpligt för ett lösenordsformulär, eftersom lösenordet skulle visas i URL:en och därmed också i webbläsarhistoriken och serverloggarna, allt i klartext. Det är inte heller lämpligt för stora datamängder eller för binära data, t.ex. en bild. En webbapplikation som använder GET-begäranden för administratörsformulär är en säkerhetsrisk: det kan vara lätt för en angripare att efterlikna ett formulärs begäran för att få tillgång till känsliga delar av systemet. POST, i kombination med andra skydd som Djangos CSRF-skydd ger mer kontroll över åtkomsten.
Å andra sidan är GET lämpligt för saker som ett webbsökningsformulär, eftersom de webbadresser som representerar en GET-begäran enkelt kan bokmärkas, delas eller skickas igen.
Att hantera formulär är en komplex verksamhet. Tänk på Djangos admin, där många dataobjekt av flera olika typer kan behöva förberedas för visning i ett formulär, återges som HTML, redigeras med hjälp av ett bekvämt gränssnitt, returneras till servern, valideras och rensas upp och sedan sparas eller skickas vidare för vidare bearbetning.
\nDjangos formulärfunktionalitet kan förenkla och automatisera stora delar av detta arbete, och kan dessutom göra det på ett säkrare sätt än vad de flesta programmerare skulle kunna göra i kod som de själva skrivit.
\nDjango hanterar tre olika delar av arbetet med formulär:
\nförbereda och omstrukturera data för att göra dem redo för rendering
skapa HTML-formulär för data
ta emot och bearbeta inlämnade formulär och uppgifter från kunden
Det är möjligt att skriva kod som gör allt detta manuellt, men Django kan ta hand om allt åt dig.
\nVi har beskrivit HTML-formulär kortfattat, men en HTML <form> är bara en del av det maskineri som krävs.
I samband med en webbapplikation kan ”formulär” hänvisa till HTML <form>, eller till Django Form som producerar det, eller till de strukturerade data som returneras när det skickas in, eller till den genomgående fungerande samlingen av dessa delar.
Form-klassenLink to this heading#Kärnan i detta system av komponenter är Djangos klass Form. På ungefär samma sätt som en Django-modell beskriver den logiska strukturen hos ett objekt, dess beteende och hur dess delar representeras för oss, beskriver en Form-klass ett formulär och bestämmer hur det fungerar och ser ut.
På liknande sätt som en modellklass fält mappar till databasfält, mappar en formulärklass fält till HTML-formulär <input> element. (En ModelForm mappar en modellklass fält till HTML-formulär <input> element via en Form; detta är vad Django admin är baserad på)
Fälten i ett formulär är själva klasser; de hanterar formulärdata och utför validering när ett formulär skickas in. En DateField och en FileField hanterar mycket olika typer av data och måste göra olika saker med dem.
Ett formulärfält representeras för en användare i webbläsaren som en HTML-”widget” - en del av användargränssnittet. Varje fälttyp har en lämplig standard Widget-klass, men dessa kan åsidosättas efter behov.
\nNär vi renderar ett objekt i Django gör vi det i allmänhet:
\nfå tag på den i vyn (hämta den från databasen, till exempel)
skicka det till mallkontexten
expandera den till HTML-markup med hjälp av mallvariabler
Rendering av ett formulär i en mall innebär nästan samma arbete som rendering av alla andra typer av objekt, men det finns några viktiga skillnader.
\nNär det gäller en modellinstans som inte innehåller några data skulle det sällan eller aldrig vara användbart att göra något med den i en mall. Å andra sidan är det helt logiskt att rendera ett obefolkat formulär - det är vad vi gör när vi vill att användaren ska fylla i det.
\nSå när vi hanterar en modellinstans i en vy hämtar vi den vanligtvis från databasen. När vi hanterar ett formulär instansierar vi det vanligtvis i vyn.
\nNär vi instansierar ett formulär kan vi välja att lämna det tomt eller fylla i det i förväg, till exempel med:
\ndata från en sparad modellinstans (som i fallet med adminformulär för redigering)
uppgifter som vi har samlat in från andra källor
data som mottagits från en tidigare HTML-formulärinlämning
Det sista av dessa fall är det mest intressanta, eftersom det är det som gör det möjligt för användare att inte bara läsa en webbplats utan också skicka information tillbaka till den.
\nAnta att du vill skapa ett enkelt formulär på din webbplats för att få fram användarens namn. Du skulle behöva något liknande i din mall:
\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>\nDetta säger till webbläsaren att returnera formulärdata till URL:en /ditt-namn/, med hjälp av metoden POST. Det kommer att visa ett textfält, märkt ”Ditt namn:”, och en knapp märkt ”OK”. Om mallkontexten innehåller variabeln current_name kommer den att användas för att förfylla fältet your_name.
Du behöver en vy som renderar mallen som innehåller HTML-formuläret, och som kan tillhandahålla fältet current_name på lämpligt sätt.
När formuläret skickas in kommer POST-begäran som skickas till servern att innehålla formulärdata.
Nu behöver du också en vy som motsvarar URL:en ”ditt namn” och som hittar lämpliga nyckel-/värdepar i begäran och sedan bearbetar dem.
\nDet här är ett mycket enkelt formulär. I praktiken kan ett formulär innehålla dussintals eller hundratals fält, varav många kan behöva fyllas i i förväg, och vi kan förvänta oss att användaren arbetar igenom redigera-sänd-cykeln flera gånger innan han avslutar åtgärden.
\nVi kan kräva att viss validering sker i webbläsaren, till och med innan formuläret skickas in; vi kanske vill använda mycket mer komplexa fält, som gör att användaren kan göra saker som att välja datum från en kalender och så vidare.
\nI det här läget är det mycket enklare att få Django att göra det mesta av det här arbetet åt oss.
\nVi vet redan hur vi vill att vårt HTML-formulär ska se ut. Vår startpunkt för det i Django är detta:
\nforms.pyfrom django import forms\n\n\nclass NameForm(forms.Form):\n your_name = forms.CharField(label="Your name", max_length=100)\nDetta definierar en Form-klass med ett enda fält (your_name). Vi har använt en människovänlig etikett för fältet, som kommer att visas i <label> när det renderas (även om label som vi angav i det här fallet faktiskt är samma som skulle genereras automatiskt om vi hade utelämnat den).
Fältets maximalt tillåtna längd definieras av max_length. Detta gör två saker. Det sätter en maxlength="100" på HTML <input> (så att webbläsaren ska förhindra användaren från att ange mer än det antalet tecken i första hand). Det betyder också att när Django får tillbaka formuläret från webbläsaren, kommer det att validera längden på data.
A Form instance has an is_valid() method, which runs\nvalidation routines for all its fields. When this method is called, if all\nfields contain valid data, it will:
returnera True
placera formulärets data i dess cleaned_data-attribut.
Hela formuläret kommer att se ut så här när det visas för första gången:
\n<label for="your_name">Your name: </label>\n<input id="your_name" type="text" name="your_name" maxlength="100" required>\nObservera att den inte innehåller taggarna <form> eller en skicka-knapp. Vi måste tillhandahålla dem själva i mallen.
Formulärdata som skickas tillbaka till en Django-webbplats behandlas av en vy, vanligtvis samma vy som publicerade formuläret. Detta gör att vi kan återanvända en del av samma logik.
\nFör att hantera formuläret måste vi instansiera det i vyn för den URL där vi vill att det ska publiceras:
\nVyer.pyfrom django.http import HttpResponseRedirect\nfrom django.shortcuts import render\n\nfrom .forms import NameForm\n\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})\nOm vi kommer till den här vyn med en GET-begäran kommer den att skapa en tom formulärinstans och placera den i mallkontexten för att renderas. Det här är vad vi kan förvänta oss ska hända första gången vi besöker webbadressen.
Om formuläret skickas in med en POST-begäran kommer vyn återigen att skapa en formulärinstans och fylla den med data från begäran: form = NameForm(request.POST) Detta kallas ”binda data till formuläret” (det är nu ett bundet formulär).
Vi anropar formulärets metod is_valid(); om den inte är True går vi tillbaka till mallen med formuläret. Den här gången är formuläret inte längre tomt (unbound) så HTML-formuläret kommer att fyllas i med de data som tidigare skickats in, där de kan redigeras och korrigeras efter behov.
Om is_valid() är True kan vi nu hitta alla validerade formulärdata i dess cleaned_data-attribut. Vi kan använda dessa data för att uppdatera databasen eller göra annan bearbetning innan vi skickar en HTTP-omdirigering till webbläsaren som berättar vart den ska gå härnäst.
Vi behöver inte göra så mycket i vår mall name.html:
<form action="/your-name/" method="post">\n {% csrf_token %}\n {{ form }}\n <input type="submit" value="Submit">\n</form>\nAlla formulärets fält och deras attribut kommer att packas upp till HTML-markup från den {{ formulär }} av Djangos mallspråk.
Vi har nu ett fungerande webbformulär, beskrivet av en Django Form, bearbetat av en vy och återgivet som en HTML <form>.
Det är allt du behöver för att komma igång, men ramverket för formulär ger dig mycket mer till hands. När du har förstått grunderna i den process som beskrivs ovan bör du vara beredd att förstå andra funktioner i formulärsystemet och redo att lära dig lite mer om det underliggande maskineriet.
\nForm-klasserLink to this heading#Alla formulärklasser skapas som underklasser till antingen django.forms.Form eller django.forms.ModelForm. Du kan tänka på ModelForm som en underklass till Form. Form och ModelForm ärver faktiskt gemensam funktionalitet från en (privat) BaseForm-klass, men denna implementeringsdetalj är sällan viktig.
Skillnaden mellan Inbundna och obundna formulär är viktig:
\nEtt obundet formulär har inga data kopplade till sig. När det visas för användaren kommer det att vara tomt eller innehålla standardvärden.
Ett bundet formulär har skickat in data och kan därför användas för att avgöra om dessa data är giltiga. Om ett ogiltigt bundet formulär återges kan det innehålla inline-felmeddelanden som talar om för användaren vilka data som ska korrigeras.
Formulärets attribut is_bound talar om för dig om ett formulär har data bundna till sig eller inte.
Tänk dig ett mer användbart formulär än vårt minimala exempel ovan, som vi skulle kunna använda för att implementera ”kontakta mig”-funktionen på en personlig webbplats:
\nforms.pyfrom django import forms\n\n\nclass ContactForm(forms.Form):\n subject = forms.CharField(max_length=100)\n message = forms.CharField(widget=forms.Textarea)\n contact_email = forms.EmailField()\n urgent = forms.BooleanField(required=False)\nOur earlier form used a single field, your_name, a CharField. In\nthis case, our form has four fields: subject, message,\ncontact_email and urgent. CharField, EmailField and\nBooleanField are just three of the available field types; a full list\ncan be found in Formulärfält.
Varje formulärfält har en motsvarande Widget class, som i sin tur motsvarar en HTML-formulärwidget som till exempel <input type="text">.
I de flesta fall kommer fältet att ha en förnuftig standardwidget. Till exempel kommer ett CharField som standard att ha en TextInput-widget, som producerar en <input type="text"> i HTML. Om du behöver <textarea> istället, anger du lämplig widget när du definierar ditt formulärfält, som vi har gjort för fältet message.
Oavsett vilka data som skickas in med ett formulär, när de har validerats framgångsrikt genom att anropa is_valid() (och is_valid() har returnerat True), kommer de validerade formulärdata att finnas i ordlistan form.cleaned_data. Dessa data har på ett snyggt sätt konverterats till Python-typer åt dig.
In the contact form example above, urgent will be a boolean value.\nLikewise, fields such as IntegerField and FloatField convert\nvalues to a Python int and float respectively.
Så här skulle formulärdata kunna behandlas i den vy som hanterar formuläret:
\nVyer.pyfrom django.core.mail import EmailMessage\n\nif form.is_valid():\n subject = form.cleaned_data["subject"]\n message = form.cleaned_data["message"]\n contact_email = form.cleaned_data["contact_email"]\n urgent = form.cleaned_data["urgent"]\n\n body = (\n "Submitted through the contact form.\\n"\n f"Contact email (unverified): {contact_email}\\n"\n f"Marked urgent: {'yes' if urgent else 'no'}\\n"\n f"Message:\\n{message}"\n )\n\n # Send the message, directing replies to the contact_email.\n EmailMessage(\n subject=f"[contact form] {subject}",\n body=body,\n from_email="contact-form@example.com",\n to=["info@example.com"],\n headers={"Importance": "high"} if urgent else None,\n reply_to=[contact_email],\n ).send()\n\n return HttpResponseRedirect("/thanks/")\nVissa fälttyper behöver lite extra hantering. Till exempel måste filer som laddas upp med hjälp av ett formulär hanteras annorlunda (de kan hämtas från request.FILES, i stället för request.POST). För detaljer om hur du hanterar filuppladdningar med ditt formulär, se Binder uppladdade filer till ett formulär.
Allt du behöver göra för att få in ditt formulär i en mall är att placera formulärinstansen i mallkontexten. Så om ditt formulär kallas form i sammanhanget, kommer {{ form }} att rendera sina <label> och <input> element på lämpligt sätt.
HTML-utdata vid rendering av ett formulär genereras i sig via en mall. Du kan kontrollera detta genom att skapa en lämplig mallfil och ange en anpassad FORM_RENDERER för att använda den form_template_name på hela webbplatsen. Du kan också anpassa per formulär genom att åsidosätta formulärets template_name-attribut för att rendera formuläret med den anpassade mallen, eller genom att skicka mallnamnet direkt till Form.render().
Exemplet nedan resulterar i att {{form} återges som utdata i mallen form_snippet.html.
I dina mallar:
\n# In your template:\n{{ form }}\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 %}\nSedan kan du konfigurera inställningen FORM_RENDERER:
settings.pyfrom django.forms.renderers import TemplatesSetting\n\n\nclass CustomFormRenderer(TemplatesSetting):\n form_template_name = "form_snippet.html"\n\n\nFORM_RENDERER = "project.settings.CustomFormRenderer"\n… eller för ett enda formulär:
\nclass MyForm(forms.Form):\n template_name = "form_snippet.html"\n ...\n… eller för en enda rendering av en formulärinstans, genom att skicka in mallnamnet till Form.render(). Här är ett exempel på hur detta används i en vy:
def index(request):\n form = MyForm()\n rendered_form = form.render("form_snippet.html")\n context = {"form": rendered_form}\n return render(request, "index.html", context)\nSe Utmatning av formulär som HTML för mer information.
\nEach field is available as an attribute of the form, using\n{{ form.name_of_field }} in a template. A field has an\nas_field_group() method which renders the\nrelated elements of the field as a group: its label, widget, errors, and help\ntext.
This allows generic templates to be written that arrange each field’s elements\nin the required layout. For example:
\n{{ form.non_field_errors }}\n<div class="fieldWrapper">\n {{ form.subject.as_field_group }}\n</div>\n<div class="fieldWrapper">\n {{ form.message.as_field_group }}\n</div>\n<div class="fieldWrapper">\n {{ form.contact_email.as_field_group }}\n</div>\n<div class="fieldWrapper">\n {{ form.urgent.as_field_group }}\n</div>\nSom standard använder Django mallen "django/forms/field.html" som är utformad för användning med standardformulärsstilen "django/forms/div.html".
Standardmallen kan anpassas genom att ställa in field_template_name i din projektnivå FORM_RENDERER:
from django.forms.renderers import TemplatesSetting\n\n\nclass CustomFormRenderer(TemplatesSetting):\n field_template_name = "field_snippet.html"\n… eller på ett enda fält:
\nclass MyForm(forms.Form):\n subject = forms.CharField(template_name="my_custom_template.html")\n ...\n… eller per förfrågan genom att anropa BoundField.render() och ange ett mallnamn:
def index(request):\n form = ContactForm()\n subject = form["subject"]\n context = {"subject": subject.render("my_custom_template.html")}\n return render(request, "index.html", context)\nDet är också möjligt att få mer detaljerad kontroll över fältrenderingen. Sannolikt kommer detta att ske i en anpassad fältmall, så att mallen kan skrivas en gång och återanvändas för varje fält. Men det kan också nås direkt från fältattributet på formuläret. Ett exempel:
\n{{ 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.contact_email.errors }}\n <label for="{{ form.contact_email.id_for_label }}">Your email address:</label>\n {{ form.contact_email }}\n</div>\n<div class="fieldWrapper">\n {{ form.urgent.errors }}\n <label for="{{ form.urgent.id_for_label }}">Urgent reply needed?</label>\n {{ form.urgent }}\n</div>\nKompletta <label> element kan också genereras med hjälp av label_tag(). Till exempel:
<div class="fieldWrapper">\n {{ form.subject.errors }}\n {{ form.subject.label_tag }}\n {{ form.subject }}\n</div>\nPriset för denna flexibilitet är lite mer arbete. Hittills har vi inte behövt oroa oss för hur vi ska visa formulärfel, eftersom det har tagits hand om åt oss. I det här exemplet har vi varit tvungna att se till att vi tar hand om eventuella fel för varje fält och eventuella fel för formuläret som helhet. Notera {{ form.non_field_errors }} högst upp i formuläret och mallens uppslagning för fel i varje fält.
Om du använder {{ form.name_of_field.errors }} visas en lista över formulärfel, återgiven som en oordnad lista. Detta kan se ut så här:
<ul class="errorlist">\n <li>Contact email is required.</li>\n</ul>\nListan har CSS-klassen errorlist för att du ska kunna anpassa dess utseende. Om du vill anpassa visningen av fel ytterligare kan du göra det genom att loopa över dem:
{% 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 %}\nFel som inte är fältfel (och/eller dolda fältfel som återges högst upp i formuläret när hjälpfunktioner som form.as_p() används) kommer att återges med en extra klass nonfield för att skilja dem från fältspecifika fel. Till exempel skulle {{ form.non_field_errors }} se ut så här:
<ul class="errorlist nonfield">\n <li>Generic validation error</li>\n</ul>\nSe API för formulär för mer information om fel, styling och att arbeta med formulärattribut i mallar.
\nOm du använder samma HTML för alla dina formulärfält kan du minska dubblerad kod genom att slinga dig igenom varje fält i tur och ordning med hjälp av en {% feller %}-slinga:
{% 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" id="{{ field.auto_id }}_helptext">\n {{ field.help_text|safe }}\n </p>\n {% endif %}\n </div>\n{% endfor %}\nAnvändbara attribut på {{ field }} inkluderar:
{{ field.errors }}Skickar ut en <ul class="errorlist"> som innehåller alla valideringsfel som motsvarar detta fält. Du kan anpassa presentationen av felen med en {% for error in field.errors %} loop. I det här fallet är varje objekt i slingan en sträng som innehåller felmeddelandet.
{{ field.field }}Instansen Field från formulärklassen som denna BoundField omsluter. Du kan använda den för att komma åt Field-attribut, t.ex. {{ char_field.field.max_length }}.
{{ field.help_text }}Eventuell hjälptext som har kopplats till fältet.
\n{{ field.html_name }}Namnet på det fält som ska användas i input-elementets namnfält. Detta tar hänsyn till formulärprefixet, om det har ställts in.
\n{{ field.id_for_label }}The ID that will be used for this field (id_contact_email in the\nexample above). If you are constructing the label manually, you may want to\nuse this in lieu of label_tag. It’s also useful, for example, if you\nhave some inline JavaScript and want to avoid hardcoding the field’s ID.
{{ field.is_hidden }}Detta attribut är True om formulärfältet är ett dolt fält och False annars. Det är inte särskilt användbart som en mallvariabel, men kan vara användbart i villkorliga tester som t.ex:
{% if field.is_hidden %}\n {# Do something special #}\n{% endif %}\n{{ field.label }}The label of the field, e.g. Contact email.
{{ field.label_tag }}Fältets etikett förpackad i lämplig HTML-tagg <label>. Detta inkluderar formulärets label_suffix. Till exempel är standardvärdet för label_suffix ett kolon:
<label for="id_contact_email">Contact email:</label>\n{{ field.legend_tag }}Liknar field.label_tag men använder en <legend> tagg i stället för <label>, för widgets med flera inmatningar inslagna i en <fieldset>.
{{ field.use_fieldset }}Detta attribut är True om formulärfältets widget innehåller flera inmatningar som bör grupperas semantiskt i en <fieldset> med en <legend> för att förbättra tillgängligheten. Ett exempel på användning i en mall:
{% if field.use_fieldset %}\n <fieldset>\n {% if field.label %}{{ field.legend_tag }}{% endif %}\n{% else %}\n {% if field.label %}{{ field.label_tag }}{% endif %}\n{% endif %}\n{{ field }}\n{% if field.use_fieldset %}</fieldset>{% endif %}\n{{ field.value }}Fältets värde, t.ex. someone@example.com.
For a complete list of attributes and methods, see the reference guide for\nBoundField.
Detta täcker grunderna, men formulär kan göra mycket mer:
\n