ModelFormLink to this heading#Om du bygger en databasdriven app är chansen stor att du har formulär som är nära kopplade till Django-modeller. Till exempel kan du ha en BlogComment-modell, och du vill skapa ett formulär som låter människor skicka in kommentarer. I det här fallet skulle det vara överflödigt att definiera fälttyperna i ditt formulär, eftersom du redan har definierat fälten i din modell.
Av denna anledning tillhandahåller Django en hjälpklass som låter dig skapa en Form-klass från en Django-modell.
Till exempel:
\n>>> from django.forms import ModelForm\n>>> from myapp.models import Article\n\n# Create the form class.\n>>> class ArticleForm(ModelForm):\n... class Meta:\n... model = Article\n... fields = ["pub_date", "headline", "content", "reporter"]\n...\n\n# Creating a form to add an article.\n>>> form = ArticleForm()\n\n# Creating a form to change an existing article.\n>>> article = Article.objects.get(pk=1)\n>>> form = ArticleForm(instance=article)\nDen genererade klassen Form kommer att ha ett formulärfält för varje modellfält som anges, i den ordning som anges i attributet fields.
Varje modellfält har ett motsvarande standardformulärsfält. Till exempel representeras ett CharField i en modell som ett CharField i ett formulär. En modells ManyToManyField representeras som en MultipleChoiceField. Här är den fullständiga listan över konverteringar:
Modellfält | \nFormulärfält | \n
|---|---|
| \n | Ej representerad i formuläret | \n
| \n | Ej representerad i formuläret | \n
| \n |
| \n
| \n |
| \n
| \n |
| \n
| \n |
| \n
| \n | \n |
| \n | \n |
| \n | \n |
| \n | \n |
| \n | \n |
| \n | \n |
| \n | \n |
| \n | \n |
| \n |
| \n
| \n | \n |
| \n | \n |
| \n
| \n
| \n\n |
| \n | \n |
| \n |
| \n
| \n\n |
| \n\n |
| \n\n |
| \n | \n |
| \n | Ej representerad i formuläret | \n
| \n | \n |
| \n |
| \n
| \n | \n |
| \n | \n |
| \n | \n |
Som du kanske förväntar dig är modellfälttyperna ForeignKey och ManyToManyField specialfall:
ForeignKey representeras av django.forms.ModelChoiceField, som är en ChoiceField vars val är en modell QuerySet.
ManyToManyField representeras av django.forms.ModelMultipleChoiceField, som är en MultipleChoiceField vars val är en modell QuerySet.
Dessutom har varje genererat formulärfält attribut som är inställda enligt följande:
\nOm modellfältet har blank=True, sätts required till False på formulärfältet. Annars är required=True.
Formulärfältets label sätts till modellfältets verbose_name, med det första tecknet med stor bokstav.
Formulärfältets help_text sätts till modellfältets help_text.
Om modellfältet har choices inställt, kommer formulärfältets widget att vara inställt på Select, med val som kommer från modellfältets choices. Valmöjligheterna inkluderar normalt det tomma valet som är valt som standard. Om fältet är obligatoriskt tvingar detta användaren att göra ett val. Det tomma valet kommer inte att inkluderas om modellfältet har blank=False och ett explicit default-värde (default-värdet kommer att väljas initialt istället).
Observera slutligen att du kan åsidosätta det formulärfält som används för ett visst modellfält. Se Overstyra standardfälten nedan.
\nTänk på denna uppsättning modeller:
\nfrom django.db import models\nfrom django.forms import ModelForm\n\nTITLE_CHOICES = {\n "MR": "Mr.",\n "MRS": "Mrs.",\n "MS": "Ms.",\n}\n\n\nclass Author(models.Model):\n name = models.CharField(max_length=100)\n title = models.CharField(max_length=3, choices=TITLE_CHOICES)\n birth_date = models.DateField(blank=True, null=True)\n\n def __str__(self):\n return self.name\n\n\nclass Book(models.Model):\n name = models.CharField(max_length=100)\n authors = models.ManyToManyField(Author)\n\n\nclass AuthorForm(ModelForm):\n class Meta:\n model = Author\n fields = ["name", "title", "birth_date"]\n\n\nclass BookForm(ModelForm):\n class Meta:\n model = Book\n fields = ["name", "authors"]\nMed dessa modeller skulle ModelForm-underklasserna ovan vara ungefär likvärdiga med detta (den enda skillnaden är save()-metoden, som vi kommer att diskutera om ett ögonblick.):
from django import forms\n\n\nclass AuthorForm(forms.Form):\n name = forms.CharField(max_length=100)\n title = forms.CharField(\n max_length=3,\n widget=forms.Select(choices=TITLE_CHOICES),\n )\n birth_date = forms.DateField(required=False)\n\n\nclass BookForm(forms.Form):\n name = forms.CharField(max_length=100)\n authors = forms.ModelMultipleChoiceField(queryset=Author.objects.all())\nModelFormLink to this heading#Det finns två huvudsakliga steg i valideringen av en ModelForm:
Precis som normal formulärvalidering utlöses validering av modellformulär implicit vid anrop av is_valid() eller åtkomst till attributet errors och explicit vid anrop av full_clean(), även om du vanligtvis inte kommer att använda den senare metoden i praktiken.
Model-validering (Model.full_clean()) utlöses inom valideringssteget för formuläret, direkt efter att formulärets clean()-metod har anropats.
clean()Link to this heading#Du kan åsidosätta metoden clean() på ett modellformulär för att tillhandahålla ytterligare validering på samma sätt som du kan på ett normalt formulär.
En model form-instans som är kopplad till ett model-objekt innehåller ett instance-attribut som ger dess metoder tillgång till den specifika model-instansen.
Som en del av valideringsprocessen kommer ModelForm att anropa clean()-metoden för varje fält i din modell som har ett motsvarande fält i ditt formulär. Om du har uteslutit några modellfält kommer valideringen inte att köras på dessa fält. Se formulärsvalidering-dokumentationen för mer information om hur fältrengöring och validering fungerar.
Modellens metod clean() anropas innan någon unikhetskontroll görs. Se Validering av objekt för mer information om modellens clean()-hook.
error_messagesLink to this heading#Felmeddelanden som definieras på nivån form field eller på nivån form Meta har alltid företräde framför felmeddelanden som definieras på nivån model field.
Felmeddelanden som definieras på modellfält används endast när ValidationError uppstår under modellvalidering och inga motsvarande felmeddelanden har definierats på formulärnivå.
Du kan åsidosätta felmeddelandena från NON_FIELD_ERRORS som uppkommer vid modellvalidering genom att lägga till NON_FIELD_ERRORS-nyckeln i error_messages-ordlistan i ModelForm:s inre Meta-klass:
from django.core.exceptions import NON_FIELD_ERRORS\nfrom django.forms import ModelForm\n\n\nclass ArticleForm(ModelForm):\n class Meta:\n error_messages = {\n NON_FIELD_ERRORS: {\n "unique_together": "%(model_name)s's %(field_labels)s are not unique.",\n }\n }\nVarje ModelForm har också en save()-metod. Denna metod skapar och sparar ett databasobjekt från de data som är bundna till formuläret. En subklass av ModelForm kan acceptera en befintlig modellinstans som nyckelordsargumentet instance; om detta tillhandahålls kommer save() att uppdatera den instansen. Om det inte anges kommer save() att skapa en ny instans av den angivna modellen:
>>> from myapp.models import Article\n>>> from myapp.forms import ArticleForm\n\n# Create a form instance from POST data.\n>>> f = ArticleForm(request.POST)\n\n# Save a new Article object from the form's data.\n>>> new_article = f.save()\n\n# Create a form to edit an existing Article, but use\n# POST data to populate the form.\n>>> a = Article.objects.get(pk=1)\n>>> f = ArticleForm(request.POST, instance=a)\n>>> f.save()\nObservera att om formuläret inte har validerats, kommer anrop av save() att göra det genom att kontrollera form.errors. Ett ValueError kommer att uppstå om data i formuläret inte valideras – dvs. om form.errors utvärderas till True.
Om ett valfritt fält inte visas i formulärets data använder den resulterande modellinstansen modellfältet default, om det finns ett sådant, för det fältet. Detta beteende gäller inte för fält som använder CheckboxInput, CheckboxSelectMultiple, eller SelectMultiple (eller någon anpassad widget vars value_omitted_from_data() alltid returnerar False) eftersom en avmarkerad kryssruta och omarkerad <select multiple> inte visas i data för en HTML-formulärinlämning. Använd ett anpassat formulärfält eller en widget om du utformar ett API och vill ha ett standardfallbackbeteende för ett fält som använder en av dessa widgetar.
Denna metod save() accepterar ett valfritt nyckelordsargument commit, som accepterar antingen True eller False. Om du anropar save() med commit=False kommer den att returnera ett objekt som ännu inte har sparats i databasen. I det här fallet är det upp till dig att anropa save() på den resulterande modellinstansen. Detta är användbart om du vill göra anpassad bearbetning på objektet innan du sparar det, eller om du vill använda ett av de specialiserade modellsparingsalternativen. commit är True som standard.
En annan bieffekt av att använda commit=False är när din modell har en många-till-många-relation med en annan modell. Om din modell har en many-to-many-relation och du anger commit=False när du sparar ett formulär, kan Django inte omedelbart spara formulärdata för many-to-many-relationen. Detta beror på att det inte är möjligt att spara many-to-many-data för en instans förrän instansen finns i databasen.
För att komma runt detta problem lägger Django till en metod save_m2m() till din underklass ModelForm varje gång du sparar ett formulär med commit=False. När du manuellt har sparat den instans som produceras av formuläret kan du anropa save_m2m() för att spara formulärdata från många till många. Ett exempel:
# Create a form instance with POST data.\n>>> f = AuthorForm(request.POST)\n\n# Create, but don't save the new author instance.\n>>> new_author = f.save(commit=False)\n\n# Modify the author in some way.\n>>> new_author.some_field = "some_value"\n\n# Save the new instance.\n>>> new_author.save()\n\n# Now, save the many-to-many data for the form.\n>>> f.save_m2m()\nAnrop av save_m2m() krävs bara om du använder save(commit=False). När du använder save() på ett formulär sparas alla data - även många-till-många-data - utan att du behöver göra några ytterligare metodanrop. Ett exempel:
# Create a form instance with POST data.\n>>> a = Author()\n>>> f = AuthorForm(request.POST, instance=a)\n\n# Create and save the new author instance. There's no need to do anything else.\n>>> new_author = f.save()\nFörutom metoderna save() och save_m2m() fungerar en ModelForm på exakt samma sätt som alla andra forms-formulär. Till exempel används metoden is_valid() för att kontrollera giltigheten, metoden is_multipart() används för att avgöra om ett formulär kräver uppladdning av flera filer (och därmed om request.FILES måste skickas till formuläret), etc. Se Binder uppladdade filer till ett formulär för mer information.
Det rekommenderas starkt att du uttryckligen anger alla fält som ska redigeras i formuläret med hjälp av attributet fields. Om man inte gör det kan det lätt leda till säkerhetsproblem när ett formulär oväntat tillåter en användare att ställa in vissa fält, särskilt när nya fält läggs till i en modell. Beroende på hur formuläret renderas kanske problemet inte ens är synligt på webbsidan.
Det alternativa tillvägagångssättet skulle vara att inkludera alla fält automatiskt, eller bara ta bort vissa. Detta grundläggande tillvägagångssätt är känt för att vara mycket mindre säkert och har lett till allvarliga exploateringar på stora webbplatser (t.ex. GitHub).
\nDet finns dock två genvägar för de fall där du kan garantera att dessa säkerhetsproblem inte gäller dig:
\nSätt attributet fields till specialvärdet '__all__' för att ange att alla fält i modellen ska användas. Till exempel:
from django.forms import ModelForm\n\n\nclass AuthorForm(ModelForm):\n class Meta:\n model = Author\n fields = "__all__"\nStäll in attributet exclude i ModelForm:s inre Meta-klass till en lista över fält som ska uteslutas från formuläret.
Till exempel:
\nclass PartialAuthorForm(ModelForm):\n class Meta:\n model = Author\n exclude = ["title"]\nEftersom modellen Author har de 3 fälten name, title och birth_date, kommer detta att resultera i att fälten name och birth_date finns på formuläret.
Om något av dessa alternativ används kommer fälten att visas i formuläret i den ordning som fälten definieras i modellen, med ManyToManyField-instanser sist.
Dessutom tillämpar Django följande regel: om du ställer in editable=False på modellfältet, kommer alla formulär som skapas från modellen via ModelForm inte att innehålla det fältet.
Standardfälttyperna, som beskrivs i tabellen Field types ovan, är förnuftiga standardvärden. Om du har ett DateField i din modell är chansen stor att du vill att det ska representeras som ett DateField i ditt formulär. Men ModelForm ger dig flexibiliteten att ändra formulärfältet för en given modell.
Om du vill ange en anpassad widget för ett fält använder du attributet widgets i den inre klassen Meta. Detta bör vara en ordbok som mappar fältnamn till widgetklasser eller -instanser.
Om du till exempel vill att CharField för attributet name i Author ska representeras av en <textarea> i stället för standardvärdet <input type="text">, kan du åsidosätta fältets widget:
from django.forms import ModelForm, Textarea\nfrom myapp.models import Author\n\n\nclass AuthorForm(ModelForm):\n class Meta:\n model = Author\n fields = ["name", "title", "birth_date"]\n widgets = {\n "name": Textarea(attrs={"cols": 80, "rows": 20}),\n }\nOrdboken widgets accepterar antingen widgetinstanser (t.ex. Textarea(...)) eller klasser (t.ex. Textarea). Observera att widgets-dictionary ignoreras för ett modellfält med ett icke-tomt choices-attribut. I det här fallet måste du åsidosätta formulärfältet för att använda en annan widget.
På samma sätt kan du ange attributen labels, help_texts och error_messages i den inre klassen Meta om du vill anpassa ett fält ytterligare.
Om du till exempel vill anpassa ordalydelsen i alla strängar för fältet namn för användare:
from django.utils.translation import gettext_lazy as _\n\n\nclass AuthorForm(ModelForm):\n class Meta:\n model = Author\n fields = ["name", "title", "birth_date"]\n labels = {\n "name": _("Writer"),\n }\n help_texts = {\n "name": _("Some useful help text."),\n }\n error_messages = {\n "name": {\n "max_length": _("This writer's name is too long."),\n },\n }\nDu kan också ange field_classes eller formfield_callback för att anpassa typen av fält som instansieras av formuläret.
Om du till exempel vill använda MySlugFormField för fältet slug kan du göra följande:
from django.forms import ModelForm\nfrom myapp.models import Article\n\n\nclass ArticleForm(ModelForm):\n class Meta:\n model = Article\n fields = ["pub_date", "headline", "content", "reporter", "slug"]\n field_classes = {\n "slug": MySlugFormField,\n }\neller:
\nfrom django.forms import ModelForm\nfrom myapp.models import Article\n\n\ndef formfield_for_dbfield(db_field, **kwargs):\n if db_field.name == "slug":\n return MySlugFormField()\n return db_field.formfield(**kwargs)\n\n\nclass ArticleForm(ModelForm):\n class Meta:\n model = Article\n fields = ["pub_date", "headline", "content", "reporter", "slug"]\n formfield_callback = formfield_for_dbfield\nSlutligen, om du vill ha fullständig kontroll över ett fält - inklusive dess typ, validerare, obligatoriska osv. – kan du göra detta genom att deklarativt specificera fält som du skulle göra i en vanlig Form.
Om du vill ange ett fälts validatorer kan du göra det genom att definiera fältet deklarativt och ange parametern validators:
from django.forms import CharField, ModelForm\nfrom myapp.models import Article\n\n\nclass ArticleForm(ModelForm):\n slug = CharField(validators=[validate_slug])\n\n class Meta:\n model = Article\n fields = ["pub_date", "headline", "content", "reporter", "slug"]\nSom standard kommer fälten i ett ModelForm inte att lokalisera sina data. För att aktivera lokalisering för fält kan du använda attributet localized_fields på klassen Meta.
>>> from django.forms import ModelForm\n>>> from myapp.models import Author\n>>> class AuthorForm(ModelForm):\n... class Meta:\n... model = Author\n... localized_fields = ['birth_date']\nOm localized_fields är satt till specialvärdet '__all__', kommer alla fält att lokaliseras.
Precis som med grundläggande formulär kan du utöka och återanvända ModelForm-klasser genom att ärva dem. Detta är användbart om du behöver deklarera extra fält eller extra metoder i en överordnad klass som ska användas i ett antal formulär som härrör från modeller. Till exempel genom att använda den tidigare klassen ArticleForm:
>>> class EnhancedArticleForm(ArticleForm):\n... def clean_pub_date(self): ...\n...\nDetta skapar ett formulär som beter sig identiskt med ArticleForm, förutom att det finns lite extra validering och rengöring för fältet pub_date.
Du kan också subklassa förälderns inre klass Meta om du vill ändra listorna Meta.fields eller Meta.exclude:
>>> class RestrictedArticleForm(EnhancedArticleForm):\n... class Meta(ArticleForm.Meta):\n... exclude = ["body"]\n...\nDetta lägger till den extra metoden från EnhancedArticleForm och ändrar den ursprungliga ArticleForm.Meta för att ta bort ett fält.
Det finns dock ett par saker att notera.
\nNormala Python-regler för namnupplösning gäller. Om du har flera basklasser som deklarerar en Meta innerklass, kommer endast den första att användas. Detta innebär barnets Meta, om det finns, annars den första förälderns Meta, etc.
Det är möjligt att ärva från både Form och ModelForm samtidigt, men du måste se till att ModelForm visas först i MRO. Detta beror på att dessa klasser förlitar sig på olika metaklasser och en klass kan bara ha en metaklass.
Det är möjligt att deklarativt ta bort ett Field som ärvts från en överordnad klass genom att ställa in namnet till None i underklassen.
Du kan bara använda den här tekniken för att välja bort ett fält som definieras deklarativt av en överordnad klass; det hindrar inte metaklassen ModelForm från att generera ett standardfält. För att välja bort standardfält, se Välja de fält som ska användas.
Precis som med vanliga formulär går det att ange initiala data för formulär genom att ange en initial-parameter när formuläret instansieras. Initiala värden som anges på detta sätt åsidosätter både initiala värden från formulärfältet och värden från en ansluten modellinstans. Ett exempel:
>>> article = Article.objects.get(pk=1)\n>>> article.headline\n'My headline'\n>>> form = ArticleForm(initial={"headline": "Initial headline"}, instance=article)\n>>> form["headline"].value()\n'Initial headline'\nDu kan skapa formulär från en given modell med hjälp av den fristående funktionen modelform_factory(), istället för att använda en klassdefinition. Detta kan vara mer praktiskt om du inte har många anpassningar att göra:
>>> from django.forms import modelform_factory\n>>> from myapp.models import Book\n>>> BookForm = modelform_factory(Book, fields=["author", "title"])\nDetta kan också användas för att göra ändringar i befintliga formulär, t.ex. genom att ange vilka widgets som ska användas för ett visst fält:
\n>>> from django.forms import Textarea\n>>> Form = modelform_factory(Book, form=BookForm, widgets={"title": Textarea()})\nDe fält som ska inkluderas kan anges med hjälp av nyckelordsargumenten fields och exclude, eller motsvarande attribut på den inre Meta-klassen ModelForm. Se dokumentationen för ModelForm Välja de fält som ska användas.
… eller aktivera lokalisering för specifika fält:
\n>>> Form = modelform_factory(Author, form=AuthorForm, localized_fields=["birth_date"])\nLiksom regelbundna formulär tillhandahåller Django ett par förbättrade formulärklasser för att göra arbetet med Django-modeller mer bekvämt. Låt oss återanvända modellen Author från ovan:
>>> from django.forms import modelformset_factory\n>>> from myapp.models import Author\n>>> AuthorFormSet = modelformset_factory(Author, fields=["name", "title"])\nOm du använder fields begränsas formuläret till att endast använda de angivna fälten. Alternativt kan du välja en ”opt-out”-strategi och ange vilka fält som ska uteslutas:
>>> AuthorFormSet = modelformset_factory(Author, exclude=["birth_date"])\nDetta kommer att skapa ett formulär som kan arbeta med data som är associerade med modellen Author. Det fungerar precis som ett vanligt formulär:
>>> formset = AuthorFormSet()\n>>> print(formset)\n<input type="hidden" name="form-TOTAL_FORMS" value="1" id="id_form-TOTAL_FORMS"><input type="hidden" name="form-INITIAL_FORMS" value="0" id="id_form-INITIAL_FORMS"><input type="hidden" name="form-MIN_NUM_FORMS" value="0" id="id_form-MIN_NUM_FORMS"><input type="hidden" name="form-MAX_NUM_FORMS" value="1000" id="id_form-MAX_NUM_FORMS">\n<div><label for="id_form-0-name">Name:</label><input id="id_form-0-name" type="text" name="form-0-name" maxlength="100"></div>\n<div><label for="id_form-0-title">Title:</label><select name="form-0-title" id="id_form-0-title">\n<option value="" selected>---------</option>\n<option value="MR">Mr.</option>\n<option value="MRS">Mrs.</option>\n<option value="MS">Ms.</option>\n</select><input type="hidden" name="form-0-id" id="id_form-0-id"></div>\nNär du skapar ett formulär från en modell kommer formuläret som standard att använda en queryset som innehåller alla objekt i modellen (t.ex. Author.objects.all()). Du kan åsidosätta detta beteende genom att använda argumentet queryset:
>>> formset = AuthorFormSet(queryset=Author.objects.filter(name__startswith="O"))\nAlternativt kan du skapa en subklass som ställer in self.queryset i __init__:
from django.forms import BaseModelFormSet\nfrom myapp.models import Author\n\n\nclass BaseAuthorFormSet(BaseModelFormSet):\n def __init__(self, *args, **kwargs):\n super().__init__(*args, **kwargs)\n self.queryset = Author.objects.filter(name__startswith="O")\nSedan skickar du din BaseAuthorFormSet-klass till fabriksfunktionen:
>>> AuthorFormSet = modelformset_factory(\n... Author, fields=["name", "title"], formset=BaseAuthorFormSet\n... )\nOm du vill returnera en formuläruppsättning som inte innehåller några redan existerande instanser av modellen kan du ange en tom QuerySet:
\n>>> AuthorFormSet(queryset=Author.objects.none())\nSom standard, när du använder modelformset_factory, kommer ett modellformulär att skapas med modelform_factory(). Ofta kan det vara användbart att ange ett anpassat modellformulär. Du kan till exempel skapa ett anpassat modellformulär som har anpassad validering:
class AuthorForm(forms.ModelForm):\n class Meta:\n model = Author\n fields = ["name", "title"]\n\n def clean_name(self):\n # custom validation for the name field\n ...\nSkicka sedan din modellblankett till fabriksfunktionen:
\nAuthorFormSet = modelformset_factory(Author, form=AuthorForm)\nDet är inte alltid nödvändigt att definiera ett eget modellformulär. Funktionen modelformset_factory har flera argument som skickas till modelform_factory och som beskrivs nedan.
widgetsLink to this heading#Med hjälp av parametern widgets kan du ange en ordbok med värden för att anpassa ModelForm:s widgetklass för ett visst fält. Detta fungerar på samma sätt som widgets-ordlistan på den inre Meta-klassen i en ModelForm fungerar:
>>> AuthorFormSet = modelformset_factory(\n... Author,\n... fields=["name", "title"],\n... widgets={"name": Textarea(attrs={"cols": 80, "rows": 20})},\n... )\nlocalized_fieldsLink to this heading#Med hjälp av parametern localized_fields kan du aktivera lokalisering för fält i formuläret.
>>> AuthorFormSet = modelformset_factory(\n... Author, fields=['name', 'title', 'birth_date'],\n... localized_fields=['birth_date'])\nOm localized_fields är satt till specialvärdet '__all__', kommer alla fält att lokaliseras.
Precis som med vanliga formuläruppsättningar är det möjligt att specificera initialdata för formulär i formuläruppsättningen genom att ange en initial-parameter när man instansierar klassen model formset som returneras av modelformset_factory(). Men med modellformsatser gäller de initiala värdena endast för extra formulär, de som inte är kopplade till en befintlig modellinstans. Om längden på initial överstiger antalet extra formulär ignoreras överskottet av initiala data. Om de extra formulären med initiala data inte ändras av användaren kommer de inte att valideras eller sparas.
Precis som med en ModelForm kan du spara data som ett modellobjekt. Detta görs med formsetets metod save():
# Create a formset instance with POST data.\n>>> formset = AuthorFormSet(request.POST)\n\n# Assuming all is valid, save the data.\n>>> instances = formset.save()\nMetoden save() returnerar de instanser som har sparats i databasen. Om data för en viss instans inte har ändrats i de bundna data sparas inte instansen i databasen och ingår inte i returvärdet (instances, i exemplet ovan).
Om fält saknas i formuläret (t.ex. för att de har uteslutits) kommer dessa fält inte att anges med metoden save(). Mer information om denna begränsning, som även gäller för vanliga modellformulär, finns i Välja vilka fält som ska användas.
Skicka commit=False för att returnera de osparade modellinstanserna:
# don't save to the database\n>>> instances = formset.save(commit=False)\n>>> for instance in instances:\n... # do something with instance\n... instance.save()\n...\nDetta ger dig möjlighet att bifoga data till instanserna innan du sparar dem i databasen. Om ditt formulär innehåller en ManyToManyField måste du också anropa formset.save_m2m() för att säkerställa att många-till-många-relationerna sparas korrekt.
När du har anropat save() kommer din formulärmodell att ha tre nya attribut som innehåller formulärets ändringar:
Precis som med vanliga formuläruppsättningar kan du använda parametrarna max_num och extra till modelformset_factory() för att begränsa antalet extra formulär som visas.
max_num förhindrar inte att befintliga objekt visas:
>>> Author.objects.order_by("name")\n<QuerySet [<Author: Charles Baudelaire>, <Author: Paul Verlaine>, <Author: Walt Whitman>]>\n\n>>> AuthorFormSet = modelformset_factory(Author, fields=["name"], max_num=1)\n>>> formset = AuthorFormSet(queryset=Author.objects.order_by("name"))\n>>> [x.name for x in formset.get_queryset()]\n['Charles Baudelaire', 'Paul Verlaine', 'Walt Whitman']\nDessutom hindrar inte extra=0 skapandet av nya modellinstanser eftersom du kan lägga till ytterligare formulär med JavaScript eller skicka ytterligare POST-data. Se Förhindrar att nya objekt skapas om hur man gör detta.
Om värdet för max_num är större än antalet befintliga relaterade objekt, kommer upp till extra ytterligare tomma formulär att läggas till i formuläruppsättningen, så länge det totala antalet formulär inte överstiger max_num:
>>> AuthorFormSet = modelformset_factory(Author, fields=["name"], max_num=4, extra=2)\n>>> formset = AuthorFormSet(queryset=Author.objects.order_by("name"))\n>>> for form in formset:\n... print(form)\n...\n<div><label for="id_form-0-name">Name:</label><input id="id_form-0-name" type="text" name="form-0-name" value="Charles Baudelaire" maxlength="100"><input type="hidden" name="form-0-id" value="1" id="id_form-0-id"></div>\n<div><label for="id_form-1-name">Name:</label><input id="id_form-1-name" type="text" name="form-1-name" value="Paul Verlaine" maxlength="100"><input type="hidden" name="form-1-id" value="3" id="id_form-1-id"></div>\n<div><label for="id_form-2-name">Name:</label><input id="id_form-2-name" type="text" name="form-2-name" value="Walt Whitman" maxlength="100"><input type="hidden" name="form-2-id" value="2" id="id_form-2-id"></div>\n<div><label for="id_form-3-name">Name:</label><input id="id_form-3-name" type="text" name="form-3-name" maxlength="100"><input type="hidden" name="form-3-id" id="id_form-3-id"></div>\nEtt värde på max_num på None (standard) sätter en hög gräns för antalet formulär som visas (1000). I praktiken är detta likvärdigt med ingen gräns.
Med hjälp av parametern edit_only kan du förhindra att nya objekt skapas:
>>> AuthorFormSet = modelformset_factory(\n... Author,\n... fields=["name", "title"],\n... edit_only=True,\n... )\nHär kommer formuläret endast att redigera befintliga Author-instanser. Inga andra objekt kommer att skapas eller redigeras.
Modellformulären är mycket lika formulären. Låt oss säga att vi vill presentera ett formulär för att redigera Author modellinstanser:
from django.forms import modelformset_factory\nfrom django.shortcuts import render\nfrom myapp.models import Author\n\n\ndef manage_authors(request):\n AuthorFormSet = modelformset_factory(Author, fields=["name", "title"])\n if request.method == "POST":\n formset = AuthorFormSet(request.POST, request.FILES)\n if formset.is_valid():\n formset.save()\n # do something.\n else:\n formset = AuthorFormSet()\n return render(request, "manage_authors.html", {"formset": formset})\nSom du kan se är visningslogiken för ett modellformulär inte drastiskt annorlunda än för ett ”vanligt” formulär. Den enda skillnaden är att vi anropar formset.save() för att spara data i databasen. (Detta beskrevs ovan, i Spara objekt i formuläret.)
clean() på en ModelFormSetLink to this heading#Precis som med en ModelForm kommer som standard clean()-metoden för en ModelFormSet att validera att inget av objekten i formuläret bryter mot de unika begränsningarna i din modell (antingen unique, unique_together eller unique_for_date|month|year). Om du vill åsidosätta metoden clean() på en ModelFormSet och behålla denna validering måste du anropa den överordnade klassens metod clean:
from django.forms import BaseModelFormSet\n\n\nclass MyModelFormSet(BaseModelFormSet):\n def clean(self):\n super().clean()\n # example custom validation across forms in the formset\n for form in self.forms:\n # your custom formset validation\n ...\nObservera också att när du kommer till det här steget har individuella modellinstanser redan skapats för varje Form. Att ändra ett värde i form.cleaned_data är inte tillräckligt för att påverka det sparade värdet. Om du vill ändra ett värde i ModelFormSet.clean() måste du ändra form.instance:
from django.forms import BaseModelFormSet\n\n\nclass MyModelFormSet(BaseModelFormSet):\n def clean(self):\n super().clean()\n\n for form in self.forms:\n name = form.cleaned_data["name"].upper()\n form.cleaned_data["name"] = name\n # update the instance value.\n form.instance.name = name\nSom tidigare nämnts kan du åsidosätta den förvalda queryset som används av modellen formset:
\nfrom django.forms import modelformset_factory\nfrom django.shortcuts import render\nfrom myapp.models import Author\n\n\ndef manage_authors(request):\n AuthorFormSet = modelformset_factory(Author, fields=["name", "title"])\n queryset = Author.objects.filter(name__startswith="O")\n if request.method == "POST":\n formset = AuthorFormSet(\n request.POST,\n request.FILES,\n queryset=queryset,\n )\n if formset.is_valid():\n formset.save()\n # Do something.\n else:\n formset = AuthorFormSet(queryset=queryset)\n return render(request, "manage_authors.html", {"formset": formset})\nObservera att vi skickar argumentet queryset i både POST och GET-fallen i detta exempel.
Det finns tre sätt att rendera en formuläruppsättning i en Django-mall.
\nFör det första kan du låta formuläret göra det mesta av jobbet:
\n<form method="post">\n {{ formset }}\n</form>\nFör det andra kan du manuellt rendera formuläruppsättningen, men låta formuläret sköta sig självt:
\n<form method="post">\n {{ formset.management_form }}\n {% for form in formset %}\n {{ form }}\n {% endfor %}\n</form>\nNär du manuellt renderar formulären själv, se till att rendera förvaltningsformuläret enligt ovan. Se dokumentation för förvaltningsformulär.
\nFör det tredje kan du göra en manuell rendering av varje fält:
\n<form method="post">\n {{ formset.management_form }}\n {% for form in formset %}\n {% for field in form %}\n {{ field.label_tag }} {{ field }}\n {% endfor %}\n {% endfor %}\n</form>\nOm du väljer att använda den här tredje metoden och inte itererar över fälten med en {% feller %}-loop, måste du rendera fältet för primärnyckeln. Om du till exempel skulle rendera fälten namn och ålder i en modell:
<form method="post">\n {{ formset.management_form }}\n {% for form in formset %}\n {{ form.id }}\n <ul>\n <li>{{ form.name }}</li>\n <li>{{ form.age }}</li>\n </ul>\n {% endfor %}\n</form>\nLägg märke till hur vi uttryckligen måste rendera {{ form.id }}. Detta säkerställer att modellformuläret, i fallet POST, kommer att fungera korrekt. (I det här exemplet antas en primärnyckel med namnet id. Om du uttryckligen har definierat din egen primärnyckel som inte heter id, se till att den renderas)
Inline-formulär är ett litet abstraktionslager ovanpå modellformulären. Dessa förenklar fallet med att arbeta med relaterade objekt via en främmande nyckel. Anta att du har dessa två modeller:
\nfrom django.db import models\n\n\nclass Author(models.Model):\n name = models.CharField(max_length=100)\n\n\nclass Book(models.Model):\n author = models.ForeignKey(Author, on_delete=models.CASCADE)\n title = models.CharField(max_length=100)\nOm du vill skapa ett formulär som gör att du kan redigera böcker som tillhör en viss författare kan du göra så här:
\n>>> from django.forms import inlineformset_factory\n>>> BookFormSet = inlineformset_factory(Author, Book, fields=["title"])\n>>> author = Author.objects.get(name="Mike Royko")\n>>> formset = BookFormSet(instance=author)\nBookFormSet s prefix är 'book_set' (<model name>_set ). Om Book’s ForeignKey till Author har en related_name, används den istället.
InlineFormSetLink to this heading#När du åsidosätter metoder på InlineFormSet bör du underordna dig BaseInlineFormSet snarare än BaseModelFormSet.
Till exempel, om du vill åsidosätta clean():
from django.forms import BaseInlineFormSet\n\n\nclass CustomInlineFormSet(BaseInlineFormSet):\n def clean(self):\n super().clean()\n # example custom validation across forms in the formset\n for form in self.forms:\n # your custom formset validation\n ...\nSe även Åsidosätta clean() på en ModelFormSet.
\nNär du sedan skapar din inline-formulärsats skickar du in det valfria argumentet formulärsats:
>>> from django.forms import inlineformset_factory\n>>> BookFormSet = inlineformset_factory(\n... Author, Book, fields=["title"], formset=CustomInlineFormSet\n... )\n>>> author = Author.objects.get(name="Mike Royko")\n>>> formset = BookFormSet(instance=author)\nOm din modell innehåller mer än en främmande nyckel till samma modell måste du lösa tvetydigheten manuellt med hjälp av fk_name. Tänk till exempel på följande modell:
class Friendship(models.Model):\n from_friend = models.ForeignKey(\n Friend,\n on_delete=models.CASCADE,\n related_name="from_friends",\n )\n to_friend = models.ForeignKey(\n Friend,\n on_delete=models.CASCADE,\n related_name="friends",\n )\n length_in_months = models.IntegerField()\nFör att lösa detta kan du använda fk_name till inlineformset_factory():
>>> FriendshipFormSet = inlineformset_factory(\n... Friend, Friendship, fk_name="from_friend", fields=["to_friend", "length_in_months"]\n... )\nDu kanske vill tillhandahålla en vy som gör det möjligt för en användare att redigera de relaterade objekten i en modell. Så här kan du göra det:
\ndef manage_books(request, author_id):\n author = Author.objects.get(pk=author_id)\n BookInlineFormSet = inlineformset_factory(Author, Book, fields=["title"])\n if request.method == "POST":\n formset = BookInlineFormSet(request.POST, request.FILES, instance=author)\n if formset.is_valid():\n formset.save()\n # Do something. Should generally end with a redirect. For example:\n return HttpResponseRedirect(author.get_absolute_url())\n else:\n formset = BookInlineFormSet(instance=author)\n return render(request, "manage_books.html", {"formset": formset})\nNotera hur vi skickar instance i både POST och GET fallen.
inlineformset_factory använder modelformset_factory och skickar de flesta av sina argument till modelformset_factory. Detta innebär att du kan använda parametern widgets på ungefär samma sätt som när du skickar den till modelformset_factory. Se Specificera widgets som ska användas i formuläret med widgets ovan.