Spec-Zone.ru › Django 4.1

Создание форм из моделей

ModelForm

class ModelForm

Если вы разрабатываете приложение, работающее с базой данных, есть большая вероятность, что у вас будут формы, тесно связанные с моделями Django. Например, у вас может быть модель BlogComment, и вы хотите создать форму, которая позволит людям отправлять комментарии. В этом случае определение типов полей в форме будет избыточным, поскольку поля уже определены в вашей модели.

По этой причине Django предоставляет вспомогательный класс, позволяющий создавать класс Form из модели Django.

Например:

>>> from django.forms import ModelForm
>>> from myapp.models import Article

# Create the form class.
>>> class ArticleForm(ModelForm):
...     class Meta:
...         model = Article
...         fields = ['pub_date', 'headline', 'content', 'reporter']

# Creating a form to add an article.
>>> form = ArticleForm()

# Creating a form to change an existing article.
>>> article = Article.objects.get(pk=1)
>>> form = ArticleForm(instance=article)

Типы полей

Сгенерированный класс Form будет содержать поле формы для каждого поля модели, в порядке, указанном в атрибуте fields.

Каждое поле модели имеет соответствующее стандартное поле формы. Например, CharField в модели представлен как CharField в форме. Модельное ManyToManyField представлено как MultipleChoiceField. Вот полный список преобразований:

Поле модели Поле формы
AutoField Не представлено в форме
BigAutoField Не представлено в форме
BigIntegerField IntegerField с min_value установленным в -9223372036854775808 и max_value установленным в 9223372036854775807.
BinaryField CharField, если editable в поле модели установлено в True, в противном случае не представлено в форме.
BooleanField BooleanField или NullBooleanField, если null=True.
CharField CharField с max_length установленным в max_length поля модели и empty_value установленным в None, если null=True.
DateField DateField
DateTimeField DateTimeField
DecimalField DecimalField
DurationField DurationField
EmailField EmailField
FileField FileField
FilePathField FilePathField
FloatField FloatField
ForeignKey ModelChoiceField (см. ниже)
ImageField ImageField
IntegerField IntegerField
IPAddressField IPAddressField
GenericIPAddressField GenericIPAddressField
JSONField JSONField
ManyToManyField ModelMultipleChoiceField (см. ниже)
PositiveBigIntegerField IntegerField
PositiveIntegerField IntegerField
PositiveSmallIntegerField IntegerField
SlugField SlugField
SmallAutoField Не представлено в форме
SmallIntegerField IntegerField
TextField CharField с widget=forms.Textarea
TimeField TimeField
URLField URLField
UUIDField UUIDField

Как можно было ожидать, типы полей модели ForeignKey и ManyToManyField являются специальными случаями:

  • ForeignKey представлено как django.forms.ModelChoiceField, что является ChoiceField, выборы которого — модель QuerySet.
  • ManyToManyField представлено как django.forms.ModelMultipleChoiceField, что является MultipleChoiceField, выборы которого — модель QuerySet.

Кроме того, каждое сгенерированное поле формы имеет атрибуты, установленные следующим образом:

  • Если поле модели имеет blank=True, то required устанавливается в False в поле формы. В противном случае, required=True.
  • Поле формы label устанавливается в verbose_name поля модели, с заглавной первой буквой.
  • Поле формы help_text устанавливается в help_text поля модели.
  • Если в поле модели установлено choices, то widget поля формы будет установлено в Select, с вариантами, взятыми из choices поля модели. Варианты обычно включают пустой вариант, который выбран по умолчанию. Если поле обязательно, это заставляет пользователя сделать выбор. Пустой вариант не будет включён, если в поле модели установлено blank=False и есть явное значение default (вместо этого будет выбрано значение default).

Наконец, обратите внимание, что вы можете переопределить поле формы, используемое для данного поля модели. См. Переопределение полей по умолчанию ниже.

Полный пример

Рассмотрим этот набор моделей:

from django.db import models
from django.forms import ModelForm

TITLE_CHOICES = [
    ('MR', 'Mr.'),
    ('MRS', 'Mrs.'),
    ('MS', 'Ms.'),
]

class Author(models.Model):
    name = models.CharField(max_length=100)
    title = models.CharField(max_length=3, choices=TITLE_CHOICES)
    birth_date = models.DateField(blank=True, null=True)

    def __str__(self):
        return self.name

class Book(models.Model):
    name = models.CharField(max_length=100)
    authors = models.ManyToManyField(Author)

class AuthorForm(ModelForm):
    class Meta:
        model = Author
        fields = ['name', 'title', 'birth_date']

class BookForm(ModelForm):
    class Meta:
        model = Book
        fields = ['name', 'authors']

С этими моделями, подклассы ModelForm выше примерно эквивалентны этому (единственное различие – метод save(), который мы обсудим позже):

from django import forms

class AuthorForm(forms.Form):
    name = forms.CharField(max_length=100)
    title = forms.CharField(
        max_length=3,
        widget=forms.Select(choices=TITLE_CHOICES),
    )
    birth_date = forms.DateField(required=False)

class BookForm(forms.Form):
    name = forms.CharField(max_length=100)
    authors = forms.ModelMultipleChoiceField(queryset=Author.objects.all())

Валидация на ModelForm

Валидация ModelForm включает два основных этапа:

  1. Валидация формы
  2. Валидация экземпляра модели

Как и при обычной валидации форм, валидация форм модели вызывается неявно при вызове is_valid() или при обращении к атрибуту errors, и явно при вызове full_clean(), хотя на практике вы обычно не используете последний метод.

Model валидация (Model.full_clean()) вызывается из шага валидации формы сразу после вызова метода clean() формы.

Предупреждение

Процесс очистки модифицирует экземпляр модели, переданный конструктору ModelForm различными способами. Например, все поля даты в модели преобразуются в фактические объекты даты. Неудачная валидация может оставить базовый экземпляр модели в несогласованном состоянии, поэтому его повторное использование не рекомендуется.

Переопределение метода clean()

Вы можете переопределить метод clean() в форме модели, чтобы обеспечить дополнительную валидацию аналогичным образом, как и для обычной формы.

Экземпляр формы модели, привязанный к объекту модели, будет содержать атрибут instance, который предоставляет его методам доступ к этому конкретному экземпляру модели.

Предупреждение

Метод ModelForm.clean() устанавливает флаг, который заставляет шаг валидации модели проверять уникальность полей модели, помеченных как unique, unique_together или unique_for_date|month|year.

Если вы хотите переопределить метод clean() и сохранить эту валидацию, вы должны вызвать метод родительского класса clean().

Взаимодействие с валидацией модели

В рамках процесса валидации ModelForm вызовет метод clean() каждого поля вашей модели, имеющего соответствующее поле в вашей форме. Если вы исключили какие-либо поля модели, валидация не будет выполнена для этих полей. См. документацию по валидации формы валидации формы для получения дополнительной информации о работе очистки и валидации полей.

Метод clean() модели будет вызван перед выполнением каких-либо проверок уникальности. См. Валидацию объектов для получения дополнительной информации о методе clean() модели.

Учитывая сообщения об ошибках модели

Сообщения об ошибках, определенные на уровне form field или на уровне формы Meta, всегда имеют приоритет над сообщениями об ошибках, определенными на уровне model field.

Сообщения об ошибках, определенные в model fields, используются только тогда, когда возникает ValidationError во время шага валидации модели и нет соответствующих сообщений об ошибках на уровне формы.

Вы можете переопределить сообщения об ошибках от NON_FIELD_ERRORS (вызываемого валидацией модели), добавив ключ NON_FIELD_ERRORS в словарь error_messages внутреннего класса ModelForm:

from django.core.exceptions import NON_FIELD_ERRORS
from django.forms import ModelForm

class ArticleForm(ModelForm):
    class Meta:
        error_messages = {
            NON_FIELD_ERRORS: {
                'unique_together': "%(model_name)s's %(field_labels)s are not unique.",
            }
        }

Метод save()

В каждой форме ModelForm также есть метод save(). Этот метод создаёт и сохраняет объект базы данных из данных, привязанных к форме. Подкласс ModelForm может принимать существующий экземпляр модели в качестве ключевого аргумента instance; если он предоставлен, save() обновит этот экземпляр. Если он не предоставлен, save() создаст новый экземпляр указанной модели:

>>> from myapp.models import Article
>>> from myapp.forms import ArticleForm

# Create a form instance from POST data.
>>> f = ArticleForm(request.POST)

# Save a new Article object from the form's data.
>>> new_article = f.save()

# Create a form to edit an existing Article, but use
# POST data to populate the form.
>>> a = Article.objects.get(pk=1)
>>> f = ArticleForm(request.POST, instance=a)
>>> f.save()

Обратите внимание, что если форма не была валидирована, вызов save() выполнит валидацию, проверив form.errors. Будет вызвано исключение ValueError, если данные в форме не прошли валидацию — то есть, если form.errors имеет значение True.

Если необязательное поле отсутствует в данных формы, результирующий экземпляр модели использует значение по умолчанию default для этого поля, если оно определено. Это поведение не применяется к полям, использующим CheckboxInput, CheckboxSelectMultiple или SelectMultiple (или любой пользовательский виджет, для которого метод value_omitted_from_data() всегда возвращает False) так как неотмеченный флажок и невыбранный <select multiple> не отображаются в данных отправки HTML-формы. Используйте пользовательское поле формы или виджет, если вы разрабатываете API и хотите, чтобы поведение по умолчанию по умолчанию применялось для поля, использующего один из этих виджетов.

Этот метод save() принимает необязательный ключевой аргумент commit, который принимает либо True, либо False. Если вы вызываете save() с commit=False, то она вернёт объект, который ещё не сохранён в базе данных. В этом случае вы должны вызвать save() на полученном экземпляре модели. Это полезно, если вы хотите выполнить пользовательскую обработку объекта перед сохранением или хотите использовать одну из специализированных вариантов сохранения модели. commit по умолчанию True.

Другим побочным эффектом использования commit=False является ситуация, когда ваша модель имеет отношение «многие ко многим» с другой моделью. Если ваша модель имеет отношение «многие ко многим», и вы указываете commit=False при сохранении формы, Django не может сразу сохранить данные формы для отношения «многие ко многим». Это происходит потому, что невозможно сохранить данные «многие ко многим» для экземпляра до тех пор, пока он не существует в базе данных.

Для решения этой проблемы каждый раз, когда вы сохраняете форму с использованием commit=False, Django добавляет метод save_m2m() к вашему подклассу ModelForm. После того, как вы вручную сохранили экземпляр, созданный формой, вы можете вызвать save_m2m() для сохранения данных формы «многие ко многим». Например:

# Create a form instance with POST data.
>>> f = AuthorForm(request.POST)

# Create, but don't save the new author instance.
>>> new_author = f.save(commit=False)

# Modify the author in some way.
>>> new_author.some_field = 'some_value'

# Save the new instance.
>>> new_author.save()

# Now, save the many-to-many data for the form.
>>> f.save_m2m()

Вызов save_m2m() необходим только если вы используете save(commit=False). Когда вы используете save() для формы, все данные, включая данные «многие ко многим», сохраняются без необходимости дополнительных вызовов методов. Например:

# Create a form instance with POST data.
>>> a = Author()
>>> f = AuthorForm(request.POST, instance=a)

# Create and save the new author instance. There's no need to do anything else.
>>> new_author = f.save()

Помимо методов save() и save_m2m(), форма ModelForm ведет себя точно так же, как и любая другая форма forms. Например, метод is_valid() используется для проверки валидности, метод is_multipart() используется для определения, требует ли форма многочастную загрузку файлов (и, следовательно, должен ли параметр request.FILES передаваться в форму) и т. д. Более подробную информацию см. в разделе Связывание загруженных файлов с формой.

Выбор полей для использования

Сильно рекомендуется явно устанавливать все поля, которые должны редактироваться в форме, используя атрибут fields. Отсутствие этого может привести к проблемам безопасности, когда форма неожиданно позволяет пользователю устанавливать определенные поля, особенно при добавлении новых полей в модель. В зависимости от того, как отображается форма, проблема может даже не отображаться на веб-странице.

Альтернативный подход заключался бы в автоматическом включении всех полей или удалении только некоторых. Этот основной подход известен как менее безопасный и привел к серьезным уязвимостям на крупных веб-сайтах (например, GitHub).

Однако существуют два сокращения, применимые в случаях, когда можно гарантировать, что эти проблемы безопасности к вам не относятся:

  1. Установите атрибут fields в специальное значение '__all__', чтобы указать, что должны использоваться все поля модели. Например:

    from django.forms import ModelForm
    
    class AuthorForm(ModelForm):
        class Meta:
            model = Author
            fields = '__all__'
    
  2. Установите атрибут exclude внутреннего класса ModelForm в список полей, которые нужно исключить из формы.

    Например:

    class PartialAuthorForm(ModelForm):
        class Meta:
            model = Author
            exclude = ['title']
    

    Поскольку модель Author имеет 3 поля name, title и birth_date, это приведет к тому, что поля name и birth_date будут присутствовать в форме.

Если используется любой из этих вариантов, порядок отображения полей в форме будет соответствовать порядку определения полей в модели, а экземпляры ManyToManyField будут отображаться последними.

Кроме того, Django применяет следующее правило: если вы устанавливаете editable=False для поля модели, любая форма, созданная из модели с помощью ModelForm, не будет включать это поле.

Примечание

Любые поля, не включенные в форму по вышеописанной логике, не будут установлены методом save() формы. Кроме того, если вы вручную добавите исключённые поля обратно в форму, они не будут инициализированы из экземпляра модели.

Django предотвратит любую попытку сохранения неполной модели, поэтому, если модель не допускает пустых значений для отсутствующих полей и не предоставляет значение по умолчанию для этих полей, любая попытка save() модели ModelForm с отсутствующими полями завершится неудачей. Чтобы избежать этой неудачи, вы должны создать экземпляр модели с начальными значениями для отсутствующих, но обязательных полей:

author = Author(title='Mr')
form = PartialAuthorForm(request.POST, instance=author)
form.save()

В качестве альтернативы вы можете использовать save(commit=False) и вручную установить любые дополнительные обязательные поля:

form = PartialAuthorForm(request.POST)
author = form.save(commit=False)
author.title = 'Mr'
author.save()

Дополнительную информацию об использовании save(commit=False) см. в разделе о сохранении форм.

Переопределение полей по умолчанию

Типы полей по умолчанию, как описано в таблице Типы полей выше, являются разумными значениями по умолчанию. Если у вас есть DateField в вашей модели, скорее всего, вы захотите представить её как DateField в своей форме. Но ModelForm предоставляет гибкость изменения поля формы для заданной модели.

Чтобы указать пользовательский виджет для поля, используйте атрибут widgets внутреннего класса Meta. Это должен быть словарь, сопоставляющий имена полей с классами или экземплярами виджетов.

Например, если вы хотите, чтобы CharField атрибута name для Author отображался как <textarea> вместо его значения по умолчанию <input type="text">, вы можете переопределить виджет поля:

from django.forms import ModelForm, Textarea
from myapp.models import Author

class AuthorForm(ModelForm):
    class Meta:
        model = Author
        fields = ('name', 'title', 'birth_date')
        widgets = {
            'name': Textarea(attrs={'cols': 80, 'rows': 20}),
        }

Словарь widgets принимает либо экземпляры виджетов (например, Textarea(...)), либо классы (например, Textarea). Обратите внимание, что словарь widgets игнорируется для поля модели с непустым атрибутом choices. В этом случае вы должны переопределить поле формы, чтобы использовать другой виджет.

Аналогично, вы можете указать атрибуты labels, help_texts и error_messages внутреннего класса Meta, если хотите дополнительно настроить поле.

Например, если бы вы хотели настроить текст для всех пользовательских строк для поля name, вы могли бы это сделать так:

from django.utils.translation import gettext_lazy as _

class AuthorForm(ModelForm):
    class Meta:
        model = Author
        fields = ('name', 'title', 'birth_date')
        labels = {
            'name': _('Writer'),
        }
        help_texts = {
            'name': _('Some useful help text.'),
        }
        error_messages = {
            'name': {
                'max_length': _("This writer's name is too long."),
            },
        }

Вы также можете указать field_classes для настройки типа полей, созданных формой.

Например, если вы хотели использовать MySlugFormField для поля slug, вы могли бы сделать следующее:

from django.forms import ModelForm
from myapp.models import Article

class ArticleForm(ModelForm):
    class Meta:
        model = Article
        fields = ['pub_date', 'headline', 'content', 'reporter', 'slug']
        field_classes = {
            'slug': MySlugFormField,
        }

Наконец, если вы хотите полностью контролировать поле — включая его тип, валидаторы, обязательность и т. д. — вы можете сделать это, декларативно указав поля, как и в обычной Form.

Если вы хотите указать валидаторы поля, вы можете сделать это, декларативно определив поле и установив параметр validators:

from django.forms import CharField, ModelForm
from myapp.models import Article

class ArticleForm(ModelForm):
    slug = CharField(validators=[validate_slug])

    class Meta:
        model = Article
        fields = ['pub_date', 'headline', 'content', 'reporter', 'slug']

Примечание

Когда вы явно создаете поле формы таким образом, важно понять, как ModelForm и обычные Form связаны.

ModelForm — это обычное Form, которое может автоматически генерировать определенные поля. Поля, которые генерируются автоматически, зависят от содержимого класса Meta и от полей, которые уже были определены декларативно. По сути, ModelForm будет только генерировать поля, которые отсутствуют в форме, или, другими словами, поля, которые не были определены декларативно.

Декларативно определенные поля остаются неизменными, поэтому любые настройки, внесенные в атрибуты Meta, такие как widgets, labels, help_texts или error_messages, игнорируются; они применяются только к полям, которые генерируются автоматически.

Аналогично, декларативно определенные поля не получают свои атрибуты, такие как max_length или required, от соответствующей модели. Если вы хотите сохранить поведение, заданное в модели, вы должны явно указать соответствующие аргументы при объявлении поля формы.

Например, если модель Article выглядит следующим образом:

class Article(models.Model):
    headline = models.CharField(
        max_length=200,
        null=True,
        blank=True,
        help_text='Use puns liberally',
    )
    content = models.TextField()

и вы хотите добавить некоторую пользовательскую проверку для headline, сохранив значения blank и help_text, как указано, вы можете определить ArticleForm следующим образом:

class ArticleForm(ModelForm):
    headline = MyFormField(
        max_length=200,
        required=False,
        help_text='Use puns liberally',
    )

    class Meta:
        model = Article
        fields = ['headline', 'content']

Вы должны убедиться, что тип поля формы можно использовать для заполнения соответствующего поля модели. Когда они несовместимы, вы получите ValueError, так как не происходит неявного преобразования.

Дополнительную информацию о полях и их аргументах см. в документации по полям формы.

Включение локализации полей

По умолчанию поля в ModelForm не локализуют свои данные. Чтобы включить локализации для полей, вы можете использовать атрибут localized_fields в классе Meta.

>>> from django.forms import ModelForm
>>> from myapp.models import Author
>>> class AuthorForm(ModelForm):
...     class Meta:
...         model = Author
...         localized_fields = ('birth_date',)

Если localized_fields установлено в специальное значение '__all__', все поля будут локализованы.

Наследование форм

Как и в случае с базовыми формами, вы можете расширять и повторно использовать ModelForms путем наследования. Это полезно, если вам нужно объявить дополнительные поля или методы в родительском классе для использования в ряде форм, полученных из моделей. Например, используя предыдущий класс ArticleForm:

>>> class EnhancedArticleForm(ArticleForm):
...     def clean_pub_date(self):
...         ...

Это создает форму, которая ведет себя идентично ArticleForm, за исключением некоторых дополнительных проверок и обработки для поля pub_date.

Вы также можете наследовать внутренний класс Meta родительского класса, если хотите изменить списки Meta.fields или Meta.exclude:

>>> class RestrictedArticleForm(EnhancedArticleForm):
...     class Meta(ArticleForm.Meta):
...         exclude = ('body',)

Это добавляет дополнительный метод из EnhancedArticleForm и изменяет исходный ArticleForm.Meta для удаления одного поля.

Однако следует учесть несколько моментов.

  • Применяются обычные правила разрешения имен Python. Если у вас несколько базовых классов, которые объявляют внутренний класс Meta, будет использован только первый. Это означает, что будет использован внутренний класс Meta потомка, если он есть, иначе — Meta первого родителя и т. д.
  • Можно наследоваться как от Form, так и от ModelForm одновременно, однако вы должны убедиться, что ModelForm стоит первым в MRO. Это связано с тем, что эти классы полагаются на разные метаклассы, а у класса может быть только один метакласс.
  • Можно декларативно удалить Field от родительского класса, установив имя None в дочернем классе.

    Этот метод можно использовать только для исключения поля, определенного декларативно родительским классом; он не предотвратит создание метаклассом ModelForm поля по умолчанию. Чтобы исключить поля по умолчанию, см. Выбор полей для использования.

Предоставление начальных значений

Как и в обычных формах, можно указать начальные данные для форм, указав параметр initial при создании формы. Указанные таким образом начальные значения перепишут начальные значения из поля формы и значения из прикрепленного экземпляра модели. Например:

>>> article = Article.objects.get(pk=1)
>>> article.headline
'My headline'
>>> form = ArticleForm(initial={'headline': 'Initial headline'}, instance=article)
>>> form['headline'].value()
'Initial headline'

Функция-фабрика ModelForm

Вы можете создать формы из заданной модели, используя автономную функцию modelform_factory(), вместо определения класса. Это может быть удобнее, если у вас не так много настроек:

>>> from django.forms import modelform_factory
>>> from myapp.models import Book
>>> BookForm = modelform_factory(Book, fields=("author", "title"))

Это также можно использовать для внесения изменений в существующие формы, например, указав виджеты, которые будут использоваться для данного поля:

>>> from django.forms import Textarea
>>> Form = modelform_factory(Book, form=BookForm,
...                          widgets={"title": Textarea()})

Поля для включения можно указать, используя ключевые аргументы fields и exclude, или соответствующие атрибуты во внутреннем классе ModelForm . Пожалуйста, обратитесь к документации по Выбору полей для использования.

… или включить локализация для определённых полей:

>>> Form = modelform_factory(Author, form=AuthorForm, localized_fields=("birth_date",))

Наборы форм модели

class models.BaseModelFormSet

Как и обычные наборы форм, Django предоставляет несколько улучшенных классов наборов форм, чтобы работа с моделями Django была удобнее. Давайте повторно используем модель Author из примера выше:

>>> from django.forms import modelformset_factory
>>> from myapp.models import Author
>>> AuthorFormSet = modelformset_factory(Author, fields=('name', 'title'))

Использование fields ограничивает набор форм использованием только указанных полей. В качестве альтернативы, можно использовать подход «исключения», указав поля, которые необходимо исключить:

>>> AuthorFormSet = modelformset_factory(Author, exclude=('birth_date',))

Это создаст набор форм, способный работать с данными, связанными с моделью Author. Он работает так же, как обычный набор форм:

>>> formset = AuthorFormSet()
>>> print(formset)
<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">
<tr><th><label for="id_form-0-name">Name:</label></th><td><input id="id_form-0-name" type="text" name="form-0-name" maxlength="100"></td></tr>
<tr><th><label for="id_form-0-title">Title:</label></th><td><select name="form-0-title" id="id_form-0-title">
<option value="" selected>---------</option>
<option value="MR">Mr.</option>
<option value="MRS">Mrs.</option>
<option value="MS">Ms.</option>
</select><input type="hidden" name="form-0-id" id="id_form-0-id"></td></tr>

Примечание

modelformset_factory() использует formset_factory() для генерации наборов форм. Это означает, что набор форм модели является расширением базового набора форм, который знает, как взаимодействовать с конкретной моделью.

Примечание

При использовании наследования с несколькими таблицами, формы, сгенерированные фабрикой наборов форм, будут содержать поле ссылки на родительскую запись (по умолчанию <parent_model_name>_ptr) вместо поля id.

Изменение набора запросов

По умолчанию, при создании набора форм из модели, набор форм будет использовать набор запросов, включающий все объекты в модели (например, Author.objects.all()). Можно переопределить это поведение, используя аргумент queryset.

>>> formset = AuthorFormSet(queryset=Author.objects.filter(name__startswith='O'))

В качестве альтернативы, можно создать подкласс, который устанавливает self.queryset в __init__.

from django.forms import BaseModelFormSet
from myapp.models import Author

class BaseAuthorFormSet(BaseModelFormSet):
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self.queryset = Author.objects.filter(name__startswith='O')

Затем передайте ваш класс BaseAuthorFormSet в функцию-фабрику:

>>> AuthorFormSet = modelformset_factory(
...     Author, fields=('name', 'title'), formset=BaseAuthorFormSet)

Если требуется набор форм, который не включает никакие существующие экземпляры модели, можно указать пустой набор запросов:

>>> AuthorFormSet(queryset=Author.objects.none())

Изменение формы

По умолчанию, при использовании modelformset_factory, будет создана форма модели с помощью modelform_factory(). Зачастую полезно указать пользовательскую форму модели. Например, можно создать пользовательскую форму модели с пользовательской валидацией:

class AuthorForm(forms.ModelForm):
    class Meta:
        model = Author
        fields = ('name', 'title')

    def clean_name(self):
        # custom validation for the name field
        ...

Затем передайте вашу форму модели в функцию-фабрику:

AuthorFormSet = modelformset_factory(Author, form=AuthorForm)

Определение пользовательской формы модели не всегда необходимо. Функция modelformset_factory имеет несколько аргументов, которые передаются в modelform_factory, описание которых приведено ниже.

Указание виджетов для использования в форме с widgets

Используя параметр widgets, можно указать словарь значений для настройки класса виджета ModelForm для конкретного поля. Это работает так же, как словарь widgets во внутреннем классе Meta класса ModelForm.

>>> AuthorFormSet = modelformset_factory(
...     Author, fields=('name', 'title'),
...     widgets={'name': Textarea(attrs={'cols': 80, 'rows': 20})})

Включение локализации для полей с localized_fields

Используя параметр localized_fields, можно включить локализация для полей в форме.

>>> AuthorFormSet = modelformset_factory(
...     Author, fields=('name', 'title', 'birth_date'),
...     localized_fields=('birth_date',))

Если localized_fields установлено в специальное значение '__all__', все поля будут локализованы.

Предоставление начальных значений

Как и в обычных наборах форм, можно указать начальные данные для форм в наборе форм, указав параметр initial при создании класса набора форм модели, возвращаемого modelformset_factory(). Однако в наборах форм модели начальные значения применяются только к дополнительным формам, которые не привязаны к существующему экземпляру модели. Если длина initial превышает количество дополнительных форм, избыточные начальные данные игнорируются. Если дополнительные формы с начальными данными не изменены пользователем, они не будут проверены или сохранены.

Сохранение объектов в наборе форм

Как и в случае с ModelForm, данные могут быть сохранены как объект модели. Это делается с помощью метода save() набора форм:

# Create a formset instance with POST data.
>>> formset = AuthorFormSet(request.POST)

# Assuming all is valid, save the data.
>>> instances = formset.save()

Метод save() возвращает экземпляры, которые были сохранены в базе данных. Если данные данного экземпляра не изменились в связанных данных, экземпляр не будет сохранён в базе данных и не будет включён в возвращаемое значение (instances, в примере выше).

Когда поля отсутствуют в форме (например, потому что они были исключены), эти поля не будут установлены методом save(). Более подробную информацию об этом ограничении, которое также относится к обычным ModelForms, см. в разделе Выбор полей для использования.

Передайте commit=False для возврата несохранённых экземпляров модели:

# don't save to the database
>>> instances = formset.save(commit=False)
>>> for instance in instances:
...     # do something with instance
...     instance.save()

Это даёт возможность прикрепить данные к экземплярам перед сохранением их в базе данных. Если ваш набор форм содержит ManyToManyField, вам также нужно вызвать formset.save_m2m() , чтобы убедиться, что связи «многие ко многим» сохранены должным образом.

После вызова save() ваш набор форм модели будет иметь три новых атрибута, содержащих изменения набора форм:

models.BaseModelFormSet.changed_objects
models.BaseModelFormSet.deleted_objects
models.BaseModelFormSet.new_objects

Ограничение количества редактируемых объектов

Как и в обычных наборах форм, можно использовать параметры max_num и extra для modelformset_factory(), чтобы ограничить количество дополнительных форм, отображаемых на экране.

max_num не предотвращает отображение существующих объектов:

>>> Author.objects.order_by('name')
<QuerySet [<Author: Charles Baudelaire>, <Author: Paul Verlaine>, <Author: Walt Whitman>]>

>>> AuthorFormSet = modelformset_factory(Author, fields=('name',), max_num=1)
>>> formset = AuthorFormSet(queryset=Author.objects.order_by('name'))
>>> [x.name for x in formset.get_queryset()]
['Charles Baudelaire', 'Paul Verlaine', 'Walt Whitman']

Кроме того, extra=0 не препятствует созданию новых экземпляров модели, поскольку вы можете добавлять дополнительные формы с помощью JavaScript или отправлять дополнительные данные POST. См. Предотвращение создания новых объектов для получения дополнительной информации об этом.

Если значение max_num больше, чем количество существующих связанных объектов, до extra дополнительных пустых форм будут добавлены в набор форм, при условии, что общее количество форм не превысит max_num.

>>> AuthorFormSet = modelformset_factory(Author, fields=('name',), max_num=4, extra=2)
>>> formset = AuthorFormSet(queryset=Author.objects.order_by('name'))
>>> for form in formset:
...     print(form.as_table())
<tr><th><label for="id_form-0-name">Name:</label></th><td><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"></td></tr>
<tr><th><label for="id_form-1-name">Name:</label></th><td><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"></td></tr>
<tr><th><label for="id_form-2-name">Name:</label></th><td><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"></td></tr>
<tr><th><label for="id_form-3-name">Name:</label></th><td><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"></td></tr>

Значение max_num равное None (по умолчанию) устанавливает высокую границу для количества отображаемых форм (1000). На практике это эквивалентно отсутствию ограничения.

Предотвращение создания новых объектов

Новое в Django 4.1.

Используя параметр edit_only, можно предотвратить создание новых объектов:

>>> AuthorFormSet = modelformset_factory(
...     Author,
...     fields=('name', 'title'),
...     edit_only=True,
... )

Здесь набор форм будет редактировать только существующие экземпляры Author . Другие объекты не будут созданы или изменены.

Использование набора форм модели в представлении

Наборы форм модели очень похожи на наборы форм. Допустим, нам нужно отобразить набор форм для редактирования экземпляров модели Author:

from django.forms import modelformset_factory
from django.shortcuts import render
from myapp.models import Author

def manage_authors(request):
    AuthorFormSet = modelformset_factory(Author, fields=('name', 'title'))
    if request.method == 'POST':
        formset = AuthorFormSet(request.POST, request.FILES)
        if formset.is_valid():
            formset.save()
            # do something.
    else:
        formset = AuthorFormSet()
    return render(request, 'manage_authors.html', {'formset': formset})

Как видите, логика представления набора форм модели не сильно отличается от логики «обычного» набора форм. Единственное отличие состоит в том, что мы вызываем formset.save() для сохранения данных в базе данных. (Это было описано выше в разделе Сохранение объектов в наборе форм.)

Переопределение clean() в наборе форм модели

Как и в случае с ModelForms, по умолчанию метод clean() набора форм модели проверяет, что ни один из элементов набора форм не нарушает уникальные ограничения вашей модели (либо unique, unique_together или unique_for_date|month|year). Если нужно переопределить метод clean() на наборе форм модели и сохранить эту проверку, нужно вызвать метод родительского класса clean:

from django.forms import BaseModelFormSet

class MyModelFormSet(BaseModelFormSet):
    def clean(self):
        super().clean()
        # example custom validation across forms in the formset
        for form in self.forms:
            # your custom formset validation
            ...

Также обратите внимание, что к моменту достижения этой стадии для каждого элемента Form уже созданы отдельные экземпляры модели. Изменение значения в form.cleaned_data недостаточно для изменения сохранённого значения. Если нужно изменить значение в ModelFormSet.clean(), нужно изменить form.instance.

from django.forms import BaseModelFormSet

class MyModelFormSet(BaseModelFormSet):
    def clean(self):
        super().clean()

        for form in self.forms:
            name = form.cleaned_data['name'].upper()
            form.cleaned_data['name'] = name
            # update the instance value.
            form.instance.name = name

Использование набора запросов по своему усмотрению

Как уже упоминалось, можно переопределить набор запросов по умолчанию, используемый набором форм модели:

from django.forms import modelformset_factory
from django.shortcuts import render
from myapp.models import Author

def manage_authors(request):
    AuthorFormSet = modelformset_factory(Author, fields=('name', 'title'))
    queryset = Author.objects.filter(name__startswith='O')
    if request.method == "POST":
        formset = AuthorFormSet(
            request.POST, request.FILES,
            queryset=queryset,
        )
        if formset.is_valid():
            formset.save()
            # Do something.
    else:
        formset = AuthorFormSet(queryset=queryset)
    return render(request, 'manage_authors.html', {'formset': formset})

Обратите внимание, что мы передаём аргумент queryset в обоих случаях POST и GET в этом примере.

Использование formset в шаблоне

Существует три способа отображения formset в шаблоне Django.

Во-первых, вы можете позволить formset выполнить большую часть работы:

<form method="post">
    {{ formset }}
</form>

Во-вторых, вы можете вручную отобразить formset, но позволить форме справиться со своими задачами:

<form method="post">
    {{ formset.management_form }}
    {% for form in formset %}
        {{ form }}
    {% endfor %}
</form>

Когда вы вручную отображаете формы, убедитесь, что отображаете форму управления, как показано выше. См. документацию по форме управления.

В-третьих, вы можете вручную отобразить каждое поле:

<form method="post">
    {{ formset.management_form }}
    {% for form in formset %}
        {% for field in form %}
            {{ field.label_tag }} {{ field }}
        {% endfor %}
    {% endfor %}
</form>

Если вы выберете этот третий метод и не итерируете по полям с помощью {% for %} цикла, вам нужно будет отобразить поле первичного ключа. Например, если вы отображаете поля name и age модели:

<form method="post">
    {{ formset.management_form }}
    {% for form in formset %}
        {{ form.id }}
        <ul>
            <li>{{ form.name }}</li>
            <li>{{ form.age }}</li>
        </ul>
    {% endfor %}
</form>

Обратите внимание, как нам нужно явно отобразить {{ form.id }}. Это гарантирует, что набор форм модели в случае POST будет работать правильно. (Этот пример предполагает первичный ключ под названием id. Если вы явно определили свой собственный первичный ключ, который не называется id, убедитесь, что он отображается.)

Встроенные formset

class models.BaseInlineFormSet

Встроенные formset — это небольшой абстрактный уровень поверх formset моделей. Они упрощают работу с связанными объектами через внешний ключ. Предположим, у вас есть эти две модели:

from django.db import models

class Author(models.Model):
    name = models.CharField(max_length=100)

class Book(models.Model):
    author = models.ForeignKey(Author, on_delete=models.CASCADE)
    title = models.CharField(max_length=100)

Если вы хотите создать formset, который позволит редактировать книги, принадлежащие конкретному автору, вы можете сделать это так:

>>> from django.forms import inlineformset_factory
>>> BookFormSet = inlineformset_factory(Author, Book, fields=('title',))
>>> author = Author.objects.get(name='Mike Royko')
>>> formset = BookFormSet(instance=author)

Префикс BookFormSet равен 'book_set' (<model name>_set). Если у Book связь ForeignKey с Author имеет related_name, она используется вместо этого.

Примечание

inlineformset_factory() использует modelformset_factory() и помечает can_delete=True.

См. также

Вручную отображаемые can_delete и can_order.

Переопределение методов в InlineFormSet

При переопределении методов в InlineFormSet, вы должны наследовать от BaseInlineFormSet, а не от BaseModelFormSet.

Например, если вы хотите переопределить clean():

from django.forms import BaseInlineFormSet

class CustomInlineFormSet(BaseInlineFormSet):
    def clean(self):
        super().clean()
        # example custom validation across forms in the formset
        for form in self.forms:
            # your custom formset validation
            ...

См. также Переопределение clean() в ModelFormSet.

Затем, при создании своего встроенного formset, передайте необязательный аргумент formset:

>>> from django.forms import inlineformset_factory
>>> BookFormSet = inlineformset_factory(Author, Book, fields=('title',),
...     formset=CustomInlineFormSet)
>>> author = Author.objects.get(name='Mike Royko')
>>> formset = BookFormSet(instance=author)

Несколько внешних ключей к одной модели

Если ваша модель содержит более одного внешнего ключа к одной и той же модели, вам потребуется вручную разрешить неоднозначность, используя fk_name. Например, рассмотрим следующую модель:

class Friendship(models.Model):
    from_friend = models.ForeignKey(
        Friend,
        on_delete=models.CASCADE,
        related_name='from_friends',
    )
    to_friend = models.ForeignKey(
        Friend,
        on_delete=models.CASCADE,
        related_name='friends',
    )
    length_in_months = models.IntegerField()

Для разрешения этой проблемы можно использовать fk_name для inlineformset_factory():

>>> FriendshipFormSet = inlineformset_factory(Friend, Friendship, fk_name='from_friend',
...     fields=('to_friend', 'length_in_months'))

Использование встроенного formset в представлении

Вы можете предоставить представление, которое позволит пользователю редактировать связанные объекты модели. Вот как вы можете это сделать:

def manage_books(request, author_id):
    author = Author.objects.get(pk=author_id)
    BookInlineFormSet = inlineformset_factory(Author, Book, fields=('title',))
    if request.method == "POST":
        formset = BookInlineFormSet(request.POST, request.FILES, instance=author)
        if formset.is_valid():
            formset.save()
            # Do something. Should generally end with a redirect. For example:
            return HttpResponseRedirect(author.get_absolute_url())
    else:
        formset = BookInlineFormSet(instance=author)
    return render(request, 'manage_books.html', {'formset': formset})

Обратите внимание, как мы передаём instance в обоих случаях POST и GET.

Указание виджетов для использования в встроенной форме

inlineformset_factory использует modelformset_factory и передаёт большинство своих аргументов в modelformset_factory. Это означает, что вы можете использовать параметр widgets аналогичным образом, как и при передаче его в modelformset_factory. См. Указание виджетов для использования в форме с виджетами выше.

© Django Software Foundation and individual contributors
Licensed under the BSD License.
https://docs.djangoproject.com/en/4.1/topics/forms/modelforms/

Spec-Zone.ru

Настройки Оффлайн Что нового Помощь О нас
Spec-Zone .ru
спецификации, руководства, описания, API