Работа с формами

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

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

HTML-формы

В HTML форма — это набор элементов внутри <form>...</form>, которые позволяют посетителю выполнять такие действия, как ввод текста, выбор опций, изменение объектов или элементов управления и т. д., а затем отправлять эту информацию обратно на сервер.

Некоторые из этих элементов интерфейса формы — текстовые поля или флажки — встроены в сам HTML. Другие намного сложнее; интерфейс, который открывает календарь выбора даты, позволяет перемещать ползунок или изменять элементы управления, обычно использует JavaScript и CSS, а также HTML-элементы форм <input> для достижения этих эффектов.

Помимо своих <input> элементов, форма должна указывать два параметра:

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

Например, форма входа в администрирование Django содержит несколько <input> элементов: одно type="text" для имени пользователя, одно type="password" для пароля и одно type="submit" для кнопки «Войти». Она также содержит некоторые скрытые текстовые поля, которые пользователь не видит, которые Django использует для определения дальнейших действий.

Она также сообщает браузеру, что данные формы должны быть отправлены на URL, указанный в <form> атрибуте action — /admin/ — и что они должны быть отправлены с использованием HTTP-механизма, указанного в атрибуте method — post.

Когда элемент <input type="submit" value="Log in"> активируется, данные возвращаются в /admin/.

GET и POST

GET и POST являются единственными HTTP-методами, используемыми при работе с формами.

Форма входа в Django возвращается с использованием метода POST, в котором браузер собирает данные формы, кодирует их для передачи, отправляет их на сервер и получает ответ.

GET, в отличие от этого, упаковывает отправленные данные в строку и использует её для составления URL. URL содержит адрес, куда должны быть отправлены данные, а также ключи и значения данных. Вы можете увидеть это в действии, если выполните поиск в документации Django, что приведет к URL-адресу в формате https://docs.djangoproject.com/search/?q=forms&release=1.

GET и POST обычно используются для разных целей.

Любой запрос, который может изменить состояние системы (например, запрос, который вносит изменения в базу данных), должен использовать POST. GET следует использовать только для запросов, которые не влияют на состояние системы.

GET также не подходит для формы пароля, поскольку пароль будет отображаться в URL, а также в истории браузера и журнале сервера, в открытом виде. Он также не подходит для больших объемов данных или для бинарных данных, таких как изображение. Веб-приложение, которое использует запросы GET для административных форм, представляет собой риск для безопасности: злоумышленнику легко имитировать запрос формы для доступа к чувствительным частям системы. POST, в сочетании с другими средствами защиты, такими как защита CSRF Django, обеспечивает больший контроль над доступом.

С другой стороны, GET подходит для таких вещей, как форма поиска в веб, потому что URL-адреса, представляющие запрос GET , легко закладки, можно поделиться ими или повторить запрос.

Роль Django в обработке форм

Обработка форм — это сложная задача. Рассмотрим административную панель Django, где много данных различных типов может потребоваться подготовить для отображения в форме, преобразовать в HTML, отредактировать удобным интерфейсом, вернуть на сервер, валидировать и очистить, а затем сохранить или передать на дальнейшую обработку.

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

Django обрабатывает три отдельных части работы, связанной с формами:

• подготовка и перестройка данных для их подготовки к рендерингу
• создание HTML-форм для данных
• прием и обработка отправленных форм и данных от клиента

Возможно написать код, который сделает всё это вручную, но Django может позаботиться обо всём за вас.

Формы в Django

Мы кратко описали HTML-формы, но HTML-<form> — это только одна часть механизма, необходимая для работы.

В контексте веб-приложения «форма» может относиться к этому HTML-элементу <form>, к классу Django Form, который его генерирует, к структурированным данным, возвращаемым при отправке, или к законченному комплексу этих компонентов.

Класс Django Form

В основе этой системы компонентов лежит класс Django Form. Точно так же, как модель Django описывает логическую структуру объекта, его поведение и способ представления его частей, класс Form описывает форму и определяет, как она работает и выглядит.

Так же, как поля класса модели сопоставляются с полями базы данных, поля класса формы сопоставляются с элементами HTML-формы <input>. (Класс ModelForm сопоставляет поля класса модели с элементами HTML-формы <input> через класс Form; на этом основана административная панель Django.)

Поля формы сами являются классами; они управляют данными формы и выполняют валидацию при отправке формы. Класс DateField и класс FileField обрабатывают совершенно разные типы данных и выполняют с ними разные действия.

Поле формы представлено пользователю в браузере как HTML-«виджет» — часть механизма пользовательского интерфейса. Для каждого типа поля существует соответствующий виджет по умолчанию класс виджета, но их можно переопределить по мере необходимости.

Создание, обработка и отображение форм

При отображении объекта в Django мы обычно:

1. получаем его в представлении (например, извлекаем из базы данных)
2. передаем его в контекст шаблона
3. преобразуем его в HTML-разметку с помощью переменных шаблона

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

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

Таким образом, при работе с экземпляром модели в представлении мы обычно извлекаем его из базы данных. Когда мы работаем с формой, мы обычно создаём её экземпляр в представлении.

При создании экземпляра формы мы можем выбрать оставить её пустой или заполнить, например, данными из сохранённого экземпляра модели (как в случае с формами редактирования в администрировании), данными, собранными из других источников, или данными, полученными из предыдущей отправки HTML-формы.

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

Создание формы

Необходимая работа

Предположим, вы хотите создать простую форму на своём веб-сайте, чтобы получить имя пользователя. Вам понадобится что-то вроде этого в вашем шаблоне:

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

Это сообщает браузеру вернуть данные формы на URL /your-name/, используя метод POST. Он отобразит текстовое поле с меткой «Ваше имя:» и кнопку «ОК». Если в контексте шаблона есть переменная current_name, она будет использована для предварительного заполнения поля your_name.

Вам потребуется представление, которое отображает шаблон, содержащий HTML-форму, и которое может предоставить поле current_name как нужно.

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

Теперь вам также понадобится представление, соответствующее URL /your-name/ , которое найдёт соответствующие пары «ключ-значение» в запросе и обработает их.

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

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

На этом этапе гораздо проще заставить Django выполнить большую часть этой работы за нас.

Создание формы в Django

Класс Form

Мы уже знаем, как должен выглядеть наш HTML-форма. Наш отправной пункт в Django выглядит так:

from django import forms

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

Это определяет класс Form с одним полем (your_name). Мы применили понятное для пользователя имя поля, которое будет отображаться в <label> при рендеринге (хотя в данном случае указанное нами label фактически совпадает с тем, что было бы сгенерировано автоматически, если бы мы его опустили).

Максимальная допустимая длина поля определена параметром max_length. Это делает две вещи. Оно устанавливает maxlength="100" на HTML <input> (так что браузер должен предотвратить ввод пользователем более этого количества символов). Это также означает, что при получении формы от браузера Django проверит длину данных.

Экземпляр Form имеет метод is_valid(), который выполняет процедуры проверки для всех его полей. При вызове этого метода, если все поля содержат валидные данные, он:

• вернёт True
• поместит данные формы в свой атрибут cleaned_data.

Вся форма при первом отображении будет выглядеть так:

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

Обратите внимание, что она не включает теги <form> или кнопку отправки. Мы должны предоставить их сами в шаблоне.

Обработка формы

Данные формы, отправленные на веб-сайт Django, обрабатываются представлением, обычно тем же представлением, которое вывело форму. Это позволяет повторно использовать часть логики.

Для обработки формы нам нужно создать её экземпляр в представлении для URL, куда она должна быть отправлена:

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

Если мы получаем это представление с GET запросом, оно создаст пустой экземпляр формы и поместит его в контекст шаблона для рендеринга. Это то, что можно ожидать при первом посещении URL.

Если форма отправляется с POST запросом, представление снова создаст экземпляр формы и заполнит его данными из запроса: form = NameForm(request.POST) Это называется «связыванием данных с формой» (теперь это связанная форма).

Мы вызываем метод is_valid() формы; если он не True, мы возвращаемся к шаблону с формой. На этот раз форма больше не пуста (несвязанная), поэтому HTML-форма будет заполнена ранее отправленными данными, где её можно редактировать и исправлять по мере необходимости.

Если is_valid() является True, мы теперь сможем найти все проверенные данные формы в её атрибуте cleaned_data. Мы можем использовать эти данные для обновления базы данных или других операций перед отправкой HTTP-перенаправления браузеру, указывая, куда ему перейти дальше.

Шаблон

Нам не нужно делать много в нашем name.html шаблоне:

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

Все поля формы и их атрибуты будут распакованы в HTML-разметку из этого {{ form }} языком шаблонов Django.

Теперь у нас есть рабочая веб-форма, описываемая Django Form, обрабатываемая представлением и отображаемая как HTML <form>.

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

Подробнее о классах форм Django

Все классы форм создаются как подклассы либо django.forms.Form, либо django.forms.ModelForm. Можно рассматривать ModelForm как подкласс Form. Form и ModelForm фактически наследуют общие функции от (приватного) BaseForm класса, но эта деталь реализации редко важна.

Связанные и несвязанные экземпляры форм

Различие между Связанными и несвязанными формами важно:

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

Атрибут формы is_bound укажет, связаны ли с формой данные или нет.

Подробнее о полях

Рассмотрим более полезную форму, чем наш минимальный пример выше, которую мы можем использовать для реализации функциональности «свяжитесь со мной» на личном сайте:

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)

Наша предыдущая форма использовала одно поле, your_name, CharField. В этом случае наша форма имеет четыре поля: subject, message, sender и cc_myself. CharField, EmailField и BooleanField — всего лишь три из доступных типов полей; полный список можно найти в Поля форм.

Виджеты

У каждого поля формы есть соответствующий Класс виджета, который в свою очередь соответствует HTML-виджету формы, например, <input type="text">.

В большинстве случаев у поля будет разумный виджет по умолчанию. Например, по умолчанию CharField будет иметь виджет TextInput, который создаёт <input type="text"> в HTML. Если вам нужен <textarea> вместо этого, вы укажете соответствующий виджет при определении вашего поля формы, как мы сделали для поля message.

Данные полей

Какие бы данные ни были отправлены с формой, после успешной проверки, вызвав is_valid() (и is_valid() вернув True ), проверенные данные формы будут в словаре form.cleaned_data . Эти данные будут красиво преобразованы в типы Python.

В примере формы связи выше, cc_myself будет булевым значением. Аналогично, такие поля, как IntegerField и FloatField преобразуют значения в Python int и float соответственно.

Вот как данные формы могут быть обработаны в представлении, обрабатывающем эту форму:

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 = ['info@example.com']
    if cc_myself:
        recipients.append(sender)

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

Некоторые типы полей требуют дополнительной обработки. Например, файлы, загруженные с помощью формы, должны обрабатываться по-другому (они могут быть извлечены из request.FILES, а не из request.POST). Для получения подробной информации о том, как обрабатывать загрузки файлов с вашей формой, см. Связывание загруженных файлов с формой.

Работа с шаблонами форм

Для добавления вашей формы в шаблон достаточно поместить экземпляр формы в контекст шаблона. Таким образом, если ваша форма называется form в контексте, {{ form }} будут отображать её <label> и <input> элементы соответствующим образом.

Многоразовые шаблоны форм

HTML-вывод при отрисовке формы генерируется с помощью шаблона. Вы можете управлять этим, создав соответствующий файл шаблона и установив пользовательское FORM_RENDERER для использования этого form_template_name на сайте. Вы также можете настроить каждый форму, переопределяя атрибут формы template_name для отрисовки формы с помощью пользовательского шаблона или передавая имя шаблона непосредственно в Form.render().

Пример ниже приведет к отображению {{ form }} в качестве результата отрисовки шаблона form_snippet.html.

В ваших шаблонах:

# In your template:
{{ form }}

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

Затем вы можете настроить настройку FORM_RENDERER:

from django.forms.renderers import TemplatesSetting

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

FORM_RENDERER = "project.settings.CustomFormRenderer"

… или для отдельной формы:

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

… или для отдельного рендеринга экземпляра формы, передавая имя шаблона в Form.render(). Вот пример использования этого в представлении:

def index(request):
    form = MyForm()
    rendered_form = form.render("form_snippet.html")
    context = {'form': rendered_form}
    return render(request, 'index.html', context)

См. Вывод форм в виде HTML для получения дополнительной информации.

Параметры рендеринга форм

Существуют и другие варианты вывода для пар <label>/<input>:

• {{ form.as_div }} будут отображаться, заключённые в <div> теги.
• {{ form.as_table }} будут отображаться как ячейки таблицы, заключённые в <tr> теги.
• {{ form.as_p }} будут отображаться, заключённые в <p> теги.
• {{ form.as_ul }} будут отображаться, заключённые в <li> теги.

Обратите внимание, что вам необходимо будет предоставить окружающие <table> или <ul> элементы самостоятельно.

Вот вывод {{ form.as_p }} для нашего экземпляра ContactForm:

<p><label for="id_subject">Subject:</label>
    <input id="id_subject" type="text" name="subject" maxlength="100" required></p>
<p><label for="id_message">Message:</label>
    <textarea name="message" id="id_message" required></textarea></p>
<p><label for="id_sender">Sender:</label>
    <input type="email" name="sender" id="id_sender" required></p>
<p><label for="id_cc_myself">Cc myself:</label>
    <input type="checkbox" name="cc_myself" id="id_cc_myself"></p>

Обратите внимание, что каждое поле формы имеет атрибут ID, установленный на id_<field-name>, который используется тегом метки. Это важно для обеспечения доступности форм для вспомогательных технологий, таких как программы чтения с экрана. Вы также можете настроить способ генерации меток и идентификаторов.

См. Вывод форм в виде HTML для получения дополнительной информации об этом.

Отрисовка полей вручную

Мы не обязаны позволять Django распаковывать поля формы; мы можем сделать это вручную, если захотим (например, это позволит нам изменить порядок полей). Каждое поле доступно в виде атрибута формы с помощью {{ form.name_of_field }}, и в шаблоне Django будет отображаться соответствующим образом. Например:

{{ 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>

Полные <label> элементы также могут быть сгенерированы с помощью label_tag(). Например:

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

Отрисовка сообщений об ошибках формы

Цена этой гибкости — немного больше работы. До сих пор нам не приходилось беспокоиться о том, как отображать ошибки формы, так как это было сделано за нас. В этом примере мы должны убедиться, что мы обрабатываем любые ошибки для каждого поля и любые ошибки для всей формы в целом. Обратите внимание на {{ form.non_field_errors }} в верхней части формы и поиск шаблона для ошибок в каждом поле.

Использование {{ form.name_of_field.errors }} отображает список ошибок формы, отображаемых в виде неупорядоченного списка. Это может выглядеть так:

<ul class="errorlist">
    <li>Sender is required.</li>
</ul>

Список имеет CSS-класс errorlist, чтобы вы могли настроить его внешний вид. Если вы хотите дополнительно настроить отображение ошибок, вы можете сделать это, перебирая их:

{% if form.subject.errors %}
    <ol>
    {% for error in form.subject.errors %}
        <li><strong>{{ error|escape }}</strong></li>
    {% endfor %}
    </ol>
{% endif %}

Ошибки, не связанные с полями (и/или ошибки скрытых полей, которые отображаются в верхней части формы при использовании вспомогательных средств, таких как form.as_p()) будут отображаться с дополнительным классом nonfield, чтобы помочь отличить их от ошибок, связанных с полями. Например, {{ form.non_field_errors }} будет выглядеть так:

<ul class="errorlist nonfield">
    <li>Generic validation error</li>
</ul>

См. API форм для получения дополнительной информации об ошибках, форматировании и работе с атрибутами форм в шаблонах.

Перебор полей формы

Если вы используете один и тот же HTML для каждого поля формы, вы можете уменьшить дублирование кода, перебирая каждое поле по очереди с помощью цикла {% for %}:

{% for field in form %}
    <div class="fieldWrapper">
        {{ field.errors }}
        {{ field.label_tag }} {{ field }}
        {% if field.help_text %}
        <p class="help">{{ field.help_text|safe }}</p>
        {% endif %}
    </div>
{% endfor %}

Полезные атрибуты {{ field }} включают:

{{ field.errors }}

Выводит <ul class="errorlist">, содержащий любые ошибки проверки, соответствующие данному полю. Вы можете настроить отображение ошибок с помощью цикла {% for error in field.errors %}. В этом случае каждый объект в цикле — это строка, содержащая сообщение об ошибке.

{{ field.field }}

Экземпляр Field из класса формы, который оборачивает эту BoundField. Вы можете использовать его для доступа к атрибутам Field, например {{ char_field.field.max_length }}.

{{ field.help_text }}

Любой текст справки, связанный с полем.

{{ field.html_name }}

Имя поля, которое будет использоваться в поле name элемента input. Это учитывает префикс формы, если он установлен.

{{ field.id_for_label }}

Идентификатор, который будет использоваться для этого поля (id_email в примере выше). Если вы создаёте метку вручную, вы можете использовать её вместо label_tag. Это также полезно, например, если у вас есть какой-либо встроенный JavaScript и вы хотите избежать жёсткого кодирования ID поля.

{{ field.is_hidden }}

Этот атрибут True если поле формы — скрытое поле, и False в противном случае. Он не особенно полезен в качестве переменной шаблона, но может быть полезен в условных проверках, таких как:

{% if field.is_hidden %}
   {# Do something special #}
{% endif %}

{{ field.label }}

Метка поля, например Email address.

{{ field.label_tag }}

Метка поля, заключённая в соответствующий HTML <label> тег. Это включает суффикс метки формы label_suffix. Например, значение по умолчанию label_suffix — двоеточие:

<label for="id_email">Email address:</label>

{{ field.legend_tag }}

Аналогично field.label_tag , но использует тег <legend> вместо <label>, для виджетов с несколькими входными данными, заключёнными в <fieldset>, для улучшения доступности.

{{ field.use_fieldset }}

Этот атрибут True если виджет поля формы содержит несколько входных данных, которые должны быть семантически сгруппированы в <fieldset> с <legend> для повышения доступности. Пример использования в шаблоне:

{% 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 %}

{{ field.value }}

Значение поля, например someone@example.com.

Перебор скрытых и видимых полей

Если вы вручную выстраиваете форму в шаблоне, а не полагаетесь на стандартное форматирование Django, вам, возможно, захочется обращаться с полями <input type="hidden"> по-разному, чем с обычными. Например, поскольку скрытые поля ничего не отображают, вывод сообщений об ошибках «рядом» с полем может ввести пользователей в заблуждение — поэтому ошибки для этих полей следует обрабатывать иначе.

Django предоставляет два метода для формы, позволяющие перебирать скрытые и видимые поля независимо: hidden_fields() и visible_fields(). Вот изменённый пример, использующий эти два метода:

{# 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 %}

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

Дополнительные темы

Это основы, но формы могут делать гораздо больше:

• Формсеты
  • Использование начальных данных с формсетом
  • Ограничение максимального количества форм
  • Ограничение максимального количества созданных форм
  • Проверка формсета
  • Проверка количества форм в формсете
  • Обработка сортировки и удаления форм
  • Добавление дополнительных полей в формсет
  • Передача пользовательских параметров формам формсета
  • Настройка префикса формсета
  • Использование формсета в представлениях и шаблонах
• Создание форм из моделей
  • ModelForm
  • Формсеты моделей
  • Встроенные формсеты
• Активы формы (класс Media)
  • Активы как статическое определение
  • Media как динамическое свойство
  • Пути в определениях активов
  • Media объекты
  • Media на формах