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

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

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, в сочетании с другими защитами, такими как защита Django от CSRF, обеспечивает больший контроль над доступом.

С другой стороны, 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 для получения более подробной информации.

Многократно используемые шаблоны группы полей

Каждое поле доступно как атрибут формы, используя {{ form.name_of_field }} в шаблоне. Поле имеет метод as_field_group(), который отображает связанные элементы поля как группу, его метку, виджет, ошибки и подсказки.

Это позволяет писать универсальные шаблоны, которые организуют элементы полей в необходимую компоновку. Например:

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

По умолчанию Django использует шаблон "django/forms/field.html", разработанный для использования с "django/forms/div.html" стилем формы по умолчанию.

Шаблон по умолчанию можно настроить, установив field_template_name в файле настроек проекта FORM_RENDERER:

from django.forms.renderers import TemplatesSetting


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

… или для отдельного поля:

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

… или в режиме запроса, вызвав BoundField.render() и передав имя шаблона:

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

Отображение полей вручную

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

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

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

Цена этой гибкости — немного больше работы. До сих пор нам не приходилось беспокоиться о том, как отображать ошибки формы, поскольку за это отвечает Django. В этом примере нам пришлось убедиться, что мы обрабатываем любые ошибки для каждого поля и любые ошибки для формы в целом. Обратите внимание на {{ 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" id="{{ field.auto_id }}_helptext">
            {{ 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 }}

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

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