Arbeta med formulär

Om detta dokument

Detta dokument ger en introduktion till grunderna i webbformulär och hur de hanteras i Django. För en mer detaljerad titt på specifika områden av formulär-API:et, se API för formulär, Formulärfält och Validering av formulär och fält.

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.

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

HTML-formulär

I 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 POST

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.

Djangos roll i formulär

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.

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

Django hanterar tre olika delar av arbetet med formulär:

• fö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.

Formulär i Django

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

Django Form-klassen

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.

Instansiering, bearbetning och rendering av formulär

När vi renderar ett objekt i Django gör vi det i allmänhet:

1. få tag på den i vyn (hämta den från databasen, till exempel)

2. skicka det till mallkontexten

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

Nä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.

Så 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.

Nä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:

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

Bygga upp ett formulär

Det arbete som behöver göras

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

<form action="/your-name/" method="post">
    <label for="your_name">Your name: </label>
    <input id="your_name" type="text" name="your_name" value="{{ current_name }}">
    <input type="submit" value="OK">
</form>

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

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

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

I det här läget är det mycket enklare att få Django att göra det mesta av det här arbetet åt oss.

Skapa ett formulär i Django

Klassen :class:`Form

Vi vet redan hur vi vill att vårt HTML-formulär ska se ut. Vår startpunkt för det i Django är detta:

forms.py

from django import forms


class NameForm(forms.Form):
    your_name = forms.CharField(label="Your name", max_length=100)

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

En Form-instans har en is_valid()-metod, som kör valideringsrutiner för alla dess fält. När denna metod anropas, om alla fält innehåller giltiga data, kommer den att:

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

<label for="your_name">Your name: </label>
<input id="your_name" type="text" name="your_name" maxlength="100" required>

Observera att den inte innehåller taggarna <form> eller en skicka-knapp. Vi måste tillhandahålla dem själva i mallen.

Utsikten

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.

För att hantera formuläret måste vi instansiera det i vyn för den URL där vi vill att det ska publiceras:

Vyer.py

from django.http import HttpResponseRedirect
from django.shortcuts import render

from .forms import NameForm


def get_name(request):
    # if this is a POST request we need to process the form data
    if request.method == "POST":
        # create a form instance and populate it with data from the request:
        form = NameForm(request.POST)
        # check whether it's valid:
        if form.is_valid():
            # process the data in form.cleaned_data as required
            # ...
            # redirect to a new URL:
            return HttpResponseRedirect("/thanks/")

    # if a GET (or any other method) we'll create a blank form
    else:
        form = NameForm()

    return render(request, "name.html", {"form": form})

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

Mallen

Vi behöver inte göra så mycket i vår mall name.html:

<form action="/your-name/" method="post">
    {% csrf_token %}
    {{ form }}
    <input type="submit" value="Submit">
</form>

Alla formulärets fält och deras attribut kommer att packas upp till HTML-markup från den {{ formulär }} av Djangos mallspråk.

Formulär och skydd mot Cross Site Request Forgery

Django levereras med ett lättanvänt skydd mot Cross Site Request Forgeries. När du skickar in ett formulär via POST med CSRF-skydd aktiverat måste du använda csrf_token mall tagg som i föregående exempel. Eftersom CSRF-skydd inte är direkt kopplat till formulär i mallar utelämnas dock denna tagg i följande exempel i detta dokument.

HTML5-ingångstyper och webbläsarvalidering

Om ditt formulär innehåller en URLField, en EmailField eller någon heltalsfältstyp, kommer Django att använda HTML5-ingångstyperna url, email och number. Som standard kan webbläsare tillämpa sin egen validering på dessa fält, vilket kan vara strängare än Djangos validering. Om du vill inaktivera detta beteende, ställ in attributet novalidate på taggen form, eller ange en annan widget på fältet, som TextInput.

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.

Mer om Django Form-klasser

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.

Modeller och formulär

Om ditt formulär ska användas för att direkt lägga till eller redigera en Django-modell kan en ModelForm faktiskt spara dig en hel del tid, ansträngning och kod, eftersom det kommer att bygga ett formulär, tillsammans med lämpliga fält och deras attribut, från en Model-klass.

Bindande och obundna forminstanser

Skillnaden mellan Inbundna och obundna formulär är viktig:

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

Mer om fält

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:

forms.py

from django import forms


class ContactForm(forms.Form):
    subject = forms.CharField(max_length=100)
    message = forms.CharField(widget=forms.Textarea)
    sender = forms.EmailField()
    cc_myself = forms.BooleanField(required=False)

Vårt tidigare formulär använde ett enda fält, your_name, en CharField. I det här fallet har vårt formulär fyra fält: subject, message, sender och cc_myself. CharField, EmailField och BooleanField är bara tre av de tillgängliga fälttyperna; en fullständig lista finns i Formulärfält.

Widgets

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.

Fältdata

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.

Observera

Du kan fortfarande komma åt de icke validerade uppgifterna direkt från request.POST vid denna tidpunkt, men de validerade uppgifterna är bättre.

I exemplet med kontaktformuläret ovan kommer cc_myself att vara ett booleskt värde. På samma sätt konverterar fält som IntegerField och FloatField värden till Pythons int respektive float.

Så här skulle formulärdata kunna behandlas i den vy som hanterar formuläret:

Vyer.py

from django.core.mail import send_mail

if form.is_valid():
    subject = form.cleaned_data["subject"]
    message = form.cleaned_data["message"]
    sender = form.cleaned_data["sender"]
    cc_myself = form.cleaned_data["cc_myself"]

    recipients = ["[e-mail]"]
    if cc_myself:
        recipients.append(sender)

    send_mail(subject, message, sender, recipients)
    return HttpResponseRedirect("/thanks/")

Tips

För mer information om att skicka e-post från Django, se Skicka e-post.

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

Arbeta med formulärmallar

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.

Ytterligare formulärmallar för möbler

Glöm inte att ett formulärs utdata inte inkluderar de omgivande <form>-taggarna eller formulärets submit-kontroll. Du måste tillhandahålla dessa själv.

Återanvändbara formulärmallar

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:

# In your template:
{{ form }}

# In form_snippet.html:
{% for field in form %}
    <div class="fieldWrapper">
        {{ field.errors }}
        {{ field.label_tag }} {{ field }}
    </div>
{% endfor %}

Sedan kan du konfigurera inställningen FORM_RENDERER:

`ettings.py`

from django.forms.renderers import TemplatesSetting


class CustomFormRenderer(TemplatesSetting):
    form_template_name = "form_snippet.html"


FORM_RENDERER = "project.settings.CustomFormRenderer"

… eller för ett enda formulär:

class MyForm(forms.Form):
    template_name = "form_snippet.html"
    ...

… 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):
    form = MyForm()
    rendered_form = form.render("form_snippet.html")
    context = {"form": rendered_form}
    return render(request, "index.html", context)

Se Utmatning av formulär som HTML för mer information.

Återanvändbara mallar för fältgrupper

Varje fält är tillgängligt som ett attribut för formuläret med hjälp av {{ form.name_of_field }} i en mall. Ett fält har en as_field_group()-metod som återger de relaterade elementen i fältet som en grupp, dess etikett, widget, fel och hjälptext.

Detta gör det möjligt att skriva generiska mallar som ordnar fältelement i önskad layout. Till exempel:

{{ form.non_field_errors }}
<div class="fieldWrapper">
  {{ form.subject.as_field_group }}
</div>
<div class="fieldWrapper">
  {{ form.message.as_field_group }}
</div>
<div class="fieldWrapper">
  {{ form.sender.as_field_group }}
</div>
<div class="fieldWrapper">
  {{ form.cc_myself.as_field_group }}
</div>

Som 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


class CustomFormRenderer(TemplatesSetting):
    field_template_name = "field_snippet.html"

… eller på ett enda fält:

class MyForm(forms.Form):
    subject = forms.CharField(template_name="my_custom_template.html")
    ...

… eller per förfrågan genom att anropa BoundField.render() och ange ett mallnamn:

def index(request):
    form = ContactForm()
    subject = form["subject"]
    context = {"subject": subject.render("my_custom_template.html")}
    return render(request, "index.html", context)

Rendering av fält manuellt

Det ä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:

{{ form.non_field_errors }}
<div class="fieldWrapper">
    {{ form.subject.errors }}
    <label for="{{ form.subject.id_for_label }}">Email subject:</label>
    {{ form.subject }}
</div>
<div class="fieldWrapper">
    {{ form.message.errors }}
    <label for="{{ form.message.id_for_label }}">Your message:</label>
    {{ form.message }}
</div>
<div class="fieldWrapper">
    {{ form.sender.errors }}
    <label for="{{ form.sender.id_for_label }}">Your email address:</label>
    {{ form.sender }}
</div>
<div class="fieldWrapper">
    {{ form.cc_myself.errors }}
    <label for="{{ form.cc_myself.id_for_label }}">CC yourself?</label>
    {{ form.cc_myself }}
</div>

Kompletta <label> element kan också genereras med hjälp av label_tag(). Till exempel:

<div class="fieldWrapper">
    {{ form.subject.errors }}
    {{ form.subject.label_tag }}
    {{ form.subject }}
</div>

Rendering av felmeddelanden för formulär

Priset 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">
    <li>Sender is required.</li>
</ul>

Listan 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 %}
    <ol>
    {% for error in form.subject.errors %}
        <li><strong>{{ error|escape }}</strong></li>
    {% endfor %}
    </ol>
{% endif %}

Fel 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">
    <li>Generic validation error</li>
</ul>

Se API för formulär för mer information om fel, styling och att arbeta med formulärattribut i mallar.

Looping över formulärets fält

Om 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 %}
    <div class="fieldWrapper">
        {{ field.errors }}
        {{ field.label_tag }} {{ field }}
        {% if field.help_text %}
          <p class="help" id="{{ field.auto_id }}_helptext">
            {{ field.help_text|safe }}
          </p>
        {% endif %}
    </div>
{% endfor %}

Användbara attribut på {{ field }} inkluderar:

{{ fält.fel }}`

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.

{{fält.fält }}`

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

{{ fält.hjälptext }}`

Eventuell hjälptext som har kopplats till fältet.

{{ fält.html_namn }}`

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.

{{ fält.id_för_etikett }}`

Det ID som ska användas för det här fältet (id_email i exemplet ovan). Om du konstruerar etiketten manuellt kanske du vill använda detta i stället för label_tag. Det är också användbart, till exempel om du har en del JavaScript inline och vill undvika hårdkodning av fältets ID.

{{ fält.är_dold }}`

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 %}
   {# Do something special #}
{% endif %}

{{ fält.etikett }}`

Fältets beteckning, t.ex. E-postadress.

{{ 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_email">Email address:</label>

{{ fält.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>.

{{ fält.användning_fältuppsättning }}`

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 %}
  <fieldset>
  {% if field.label %}{{ field.legend_tag }}{% endif %}
{% else %}
  {% if field.label %}{{ field.label_tag }}{% endif %}
{% endif %}
{{ field }}
{% if field.use_fieldset %}</fieldset>{% endif %}

{{ fält.värde }}`

Fältets värde, t.ex. [e-mail].

Se även

För en fullständig lista över attribut och metoder, se BoundField.

Looping över dolda och synliga fält

Om du manuellt lägger ut ett formulär i en mall, i motsats till att förlita dig på Djangos standardformulärslayout, kanske du vill behandla <input type="hidden"> fält annorlunda än icke-dolda fält. Eftersom dolda fält inte visar något kan det till exempel orsaka förvirring för dina användare om du lägger felmeddelanden ”bredvid” fältet - så fel för dessa fält bör hanteras annorlunda.

Django tillhandahåller två metoder på ett formulär som gör att du kan loopa över de dolda och synliga fälten oberoende av varandra: hidden_fields() och visible_fields(). Här är en modifiering av ett tidigare exempel som använder dessa två metoder:

{# Include the hidden fields #}
{% for hidden in form.hidden_fields %}
{{ hidden }}
{% endfor %}
{# Include the visible fields #}
{% for field in form.visible_fields %}
    <div class="fieldWrapper">
        {{ field.errors }}
        {{ field.label_tag }} {{ field }}
    </div>
{% endfor %}

I det här exemplet hanteras inte eventuella fel i de dolda fälten. Vanligtvis är ett fel i ett dolt fält ett tecken på att formuläret har manipulerats, eftersom normal formulärinteraktion inte ändrar dem. Du kan dock enkelt infoga några felvisningar för dessa formulärfel också.

Ytterligare ämnen

Detta täcker grunderna, men formulär kan göra mycket mer:

• Formsatser
  • Använda initiala data med en formulärset
  • Begränsa det maximala antalet formulär
  • Begränsning av det maximala antalet instansierade formulär
  • Validering av formulär
  • Validering av antalet formulär i en formuläruppsättning
  • Hantering av beställning och borttagning av formulär
  • Lägga till ytterligare fält i en formuläruppsättning
  • Överföra anpassade parametrar till formulär
  • Anpassa prefixet för ett formulär
  • Använda en formulärsats i vyer och mallar
• Skapa formulär från modeller
  • ModelForm
  • Modellformsatser
  • Inline-formulär
• Formtillgångar (klassen ”Media”)
  • Tillgångar som en statisk definition
  • Media som en dynamisk egenskap
  • Vägar i tillgångsdefinitioner
  • Media objekt
  • Media på formulär

Se även

Formulärreferensen

Täcker hela API-referensen, inklusive formulärfält, formulärwidgets och validering av formulär och fält.