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

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

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

HTML-формы

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

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

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

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

Например, форма входа в систему для Django admin содержит несколько <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 обрабатывает три distinct части работы с формами:

• подготовка и реструктуризация данных для их подготовки к рендерингу
• создание 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>

Это сообщает браузеру вернуть данные формы по адресу /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 и вы хотите избежать жёсткой кодировки идентификатора поля.

{{ 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 в формах