forms django необязательное поле

Django Book: изменение полей на необязательные

После того как вы немного поработаете с панелью управления вы, возможно, заметите некоторые ограничения, например — форма редактирования записи требует, что бы все поля были заполнены, хотя в некоторых случаях вы хотели бы оставить их пустыми. Например, вы хотите что бы поле email модели Authors было не обязательным для заполнения (опциональным).

После того как вы добавили blank=True — перезагрузите страницу «Add author» и вы увидите, что поле Email больше не выделено жирным шрифтом. Теперь вы можете добавить нового автора без указания адреса почты — сообщений «This field is required» больше не будет.

Изменение даты и числовых полей

Описанный пример с blank=True подойдёт и для полей даты и чисел, но тут требуется дополнительное пояснение и действие.

В SQL значение NULL отличается от пустой строки, так как же специальный объект None в Python отличается от пустой строки («»). Это значит, что некоторые символьные поля (такие как VARCHAR ) могут содержать значения и NULL и пустые строки.

Это может вызвать нежелательную двусмысленность и путаницу: «Почему эта запись имеет значение NULL, а другая — пустую строку?» и «Как мне получить все записи с пустыми значениями — должен ли я искать и NULL и пустые строки, или только пустые строки?»

Что бы избежать такой путаницы — сгенерированный Django запрос CREATE TABLE (который мы рассматривали в предыдущей главе) добавляет явное указание NOT NULL для описания каждой колонки. Например, вот запрос для нашей модели Author :

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

Однако, имеются исключения, которые касаются полей типа даты, времени и чисел в вашей базе данных — они не принимают пустые строки в качестве корректных значений. Если вы попробуете добавить пустую строку в колонку с датой или цифрами — вы скорее всего получите ошибку базы данных, в зависимости от типа сервера баз данных (PostgreSQL вернёт ошибку, MySQL — может вернуть — а может и нет, в зависимости от используемой версии, времени для и фазы луны). В таком случае — NULL единственный вариант что бы задать пустое значение. В моделях Django вы можете указать, что использование NULL разрешено, добавив строку null=True к нужному полю.

Или для PostgreSQL:

Мы рассмотрим изменения схемы баз данных подробнее далее в нашей книге.

Возвращаясь к панели управления Django — теперь в форме редактирования «Add book» поле даты публикации можно оставлять пустым.

Источник

Использование форм, не связанных с моделями

На данный момент мы с вами, в целом, познакомились с механизмом маршрутизации, построения моделей, работы с шаблонами и использованием админ-панели. Конечно, это далеко не полный функционал фреймворка Django и мы еще будем возвращаться к этим темам, но на этом занятии мы коснемся новой темы – работы с формами.

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

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

в разделе «Формы», или на официальном англоязычном сайте:

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

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

Сначала мы рассмотрим форму, не связанную с моделью, хотя и сделаем это на примере добавления статей в БД. На следующем занятии модифицируем ее и превратим в форму, связанной с моделью.

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

и функция представления addpage (в файле women/views.py). Немного изменим эту функцию так, чтобы она отображала шаблон addpage.html:

А сам шаблон addpage.html определим так:

Теперь, при обновлении увидим полноценную страницу для добавления нового поста.

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

Все готово для создания формы. В Django существует специальный класс Form, на базе которого удобно создавать формы, не связанные с моделями. Где следует объявлять формы? Обычно, для этого создают в приложении отдельный файл forms.py. Мы так и сделаем (создаем файл women/forms.py). И в этом файле импортируем пакет forms и наши модели (модель Category нам здесь понадобится для формирования списка категорий):

Следующий шаг – объявить класс AddPostForm, описывающий форму добавления статьи. Он будет унаследован от базового класса Form и иметь следующий вид:

Смотрите, мы здесь определяем только те поля, с которыми будет взаимодействовать пользователь. Например, поля модели time_create или time_update нигде не фигурируют, так как заполняются автоматически. Далее, каждый атрибут формы лучше назвать также, как называются поля в таблице women. Впоследствии нам это облегчит написание кода.

В классе формы каждый атрибут – это ссылка на тот или иной экзнмпляр класса из пакета forms. Например, title определен через класс CharField, поле is_published – через BooleanField, а список категорий cat – через класс ModelChoiceField, который формируется из данных таблицы Category.

Почему указаны именно такие классы? И какие классы вообще существуют для формирования полей формы? Полный их список и назначение можно посмотреть на странице русскоязычной документации:

Я советую вам в целом изучить его и знать, как создавать различные типы полей. В частности, класс CharField служит для создания обычного поля ввода, класс BooleanField – для checkbox’а, класс ModelChoiceField – списка с данными из указанной модели.

Использование формы в функции представления

После того, как форма определена, ее можно использовать в функции представления addpage. В самом простом варианте можно записать так:

Здесь создается экземпляр формы и через переменную form передается шаблону addpage.html. Но это будет работать только при первом отображении формы, когда пользователь еще не заполнил ее поля, то есть, когда форма не ассоциирована с данными. При повторном ее отображении, например, если данные были введены некорректно и нужно показать ошибки ввода, то форма должна сохранять ранее введенную пользователем информацию. Чтобы проделать такой трюк, в функции представления пропишем следующее условие:

Мы здесь вначале проверяем, если пришел POST-запрос, значит, пользователем были отправлены данные (мы будем передавать их именно POST-запросом). В этом случае наполняем форму принятыми значениями из объекта request.POST и, затем, делаем проверку на корректность заполнения полей (метод is_valid). Если проверка прошла, то в консоли отобразим словарь form.cleaned_data полученных данных от пользователя. Если же проверка на пройдет, то пользователь увидит сообщения об ошибках. Ну, а если форма показывается первый раз (идем по else), то она формируется без параметров и отображается с пустыми полями.

Отображение формы в шаблоне

Осталось отобразить форму в нашем шаблоне. Перейдем в файл addpage.html и пропишем там следующие строчки:

Смотрите, мы самостоятельно прописываем тег для создания формы в HTML-документе, указываем через атрибут action ее обработчик (в данном случае – это тот же адрес страницы, и связанная с ним функция представления addpage). Атрибут method указывает способ передачи информации на сервер (используется POST-запрос). Внутри формы записываем специальный тег csrf_token, который генерирует скрытое поле с уникальным токеном. Это необходимо для защиты от CSRF-атак, когда на каком-либо другом сайте злоумышленник создает по виду неотличимую форму от вашего сайта и пытается заставить пользователя отправить актуальные данные на сервер через подложную форму. Фреймворк Django не станет обрабатывать данные, если отсутствует или не совпадает токен csrf-поля и, тем самым, защищает пользователя от подобных атак.

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

. Существуют и другие методы, которые формируют поля в виде элементов списка

или в виде таблицы. Последний вариант, хоть и возможен, но считается устаревшей практикой. Здесь также стоит иметь в виду, что по умолчанию все поля в Django обязательны, если не указано обратное через параметр required=False.

Наконец, последняя строчка – тег создает кнопку типа submit для запуска процесса отправки данных формы на сервер и, в конечном итоге, нашей функции представления addpage.

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

Улучшение внешнего вида формы

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

Теперь, все выглядит гораздо приятнее. Давайте для примера сделаем поле content необязательным, а поле is_published с установленной галочкой. Соответственно, в классе CharField пропишем параметр required=False, а в классе BooleanField – параметр initial=True. Еще в классе ModelChoiceField добавим параметр empty_label=»Категория не выбрана», чтобы вместо черточек отображалась по умолчанию в списке эта фраза.

Со всеми возможными параметрами можно ознакомиться в документации, все по той же ссылке:

Способы отображения формы в шаблонах

Давайте теперь посмотрим, что же в действительности представляет собой объект form на примере ручного перебора и отображения всех наших полей. Я сейчас уберу строчку << form.as_p >> и вместо нее запишу все поля формы по порядку, друг за другом.

Первое поле title мы сформируем так:

Смотрите, мы здесь самостоятельно прописали HTML-теги внутри формы. Сначала идет тег абзаца

, внутри него тег для оформления надписи. У нее указан класс оформления form-label и идентификатор через свойство form.title.id_for_label. Далее, идет само название form.title.label и после тега отображается поле для ввода заголовка form.title. Вот так можно самостоятельно расписать атрибуты объекта form внутри шаблона. Ну а следующая строчка определяет тег

с классом оформления form-error для отображения возможных ошибок при вводе неверных данных. Список ошибок доступен через переменную form.title.errors.

Все, если теперь обновить страницу сайта, то увидим это одно поле в форме. По аналогии можно прописать и все остальные поля:

А в самом верху добавим строчку:

для вывода ошибок валидации, не связанных с заполнением того или иного поля.

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

Я, думаю, этот ход вполне понятен: мы здесь на каждой итерации имеем объект поля формы и также обращаемся к нужным его атрибутам. Такая запись значительно короче и гибче в плане изменения формы (достаточно поменять класс формы и это автоматом изменит ее вид в шаблоне). Правда, все поля теперь будут иметь одни и те же стили оформления.

Однако, для виджетов стили оформлений можно прописать непосредственно в классе формы. Например, у класса поля ввода title добавить именованный параметр widget:

Мы здесь формируем виджет через класс TextInput и указываем у него стиль оформления form-input. При обновлении страницы, видим, что первое поле изменило свой вид. И так можно делать со всеми полями.

Тестирование формы

Если мы попробуем отправить пустую форму на сервер, то браузер укажет, что поле title обязательное. То же самое и для поля URL, напишем что-нибудь латинскими буквами. Выберем категорию и нажмем «Добавить». В результате, в консоли у нас отображается словарь с принятыми данными:

Все это мы можем сохранить в БД и сформировать новый пост. Если же данные в форме окажутся некорректными, например, в поле URL напишем что-то русскими буквами и сделаем отправку. Видим сообщение:

«Значение должно состоять только из латинских букв…»

и в консоли нет отображения данных, то есть, проверка не прошла. Вот так автоматически Django позволяет выполнять проверки на валидность заполненных данных.

Добавление новой записи

Теперь, когда наша форма в целом готова, выполним добавление записи в БД. Для этого после проверки валидности данных, запишем конструкцию:

Мы здесь используем ORM Django для формирования новой записи в таблице women и передаем методу create распакованный словарь полученных данных. Так как метод create может генерировать исключения, то помещаем его вызов в блок try и при успешном выполнении, осуществляется перенаправление на главную страницу. Если же возникли какие-либо ошибки, то попадаем в блок except и формируем общую ошибку для ее отображения в форме.

Давайте, для начала введем корректные данные в форму, тогда после нажатия на кнопку «Добавить» в таблице women появится новая запись с пустым полем для изображения и заполненными всеми остальными полями. Вернемся в форму и попробуем добавить статью с неуникальным слагом. Тогда возникнет исключение и мы увидим сообщение «Ошибка добавления поста». Как видите, все достаточно просто.

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

Видео по теме

#2. Модель MTV. Маршрутизация. Функции представления

#3. Маршрутизация, обработка исключений запросов, перенаправления

#4. Определение моделей. Миграции: создание и выполнение

#6. Шаблоны (templates). Начало

#7. Подключение статических файлов. Фильтры шаблонов

#8. Формирование URL-адресов в шаблонах

#9. Создание связей между моделями через класс ForeignKey

#10. Начинаем работу с админ-панелью

#11. Пользовательские теги шаблонов

#12. Добавляем слаги (slug) к URL-адресам

#13. Использование форм, не связанных с моделями

#14. Формы, связанные с моделями. Пользовательские валидаторы

#15. Классы представлений: ListView, DetailView, CreateView

#16. Основы ORM Django за час

#18. Постраничная навигация (пагинация)

#19. Регистрация пользователей на сайте

#20. Делаем авторизацию пользователей на сайте

#21. Оптимизация сайта с Django Debug Toolbar

#22. Включаем кэширование данных

#23. Использование капчи captcha

#24. Тонкая настройка админ панели

#25. Начинаем развертывание Django-сайта на хостинге

#26. Завершаем развертывание Django-сайта на хостинге

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

Источник

Forms django необязательное поле

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

Это указывает Django, что поле адреса электронной почты может быть пустым. По умолчанию, все поля имеют blank=False — это означает, что поля не могут быть пустыми.

Необязательные числовые поля и поля с датой

Особо надо отметить использование blank=True совместно с полями даты/времени и численными. Погрузимся в теорию.

Что бы избежать подобной путаницы, Django автоматически создает операторы CREATE TABLE (которые рассматривались в главе « Модели » ), добавляя явно NOT NULL к каждому полю. Например, сгенерированый запрос создания таблицы для модели Author :

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

(Обратите внимание, что такой синтаксис специфичен для PostgreSQL.)

Завершив изменения, вернёмся к интерфейсу администратора. Теперь форма редактирования книги позволяет оставлять пустой дату публикации.

1 комментарий | Оставьте комментарий

В MySQL код для изменения значения свойства поля с NOT NULL на NULL выглядит так:
ALTER TABLE books_book MODIFY books_book.publication_date date NULL;

Содержимое

Добавь себя на карту!

Нашли опечатку?

Источник

Документация Django 3.0

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

Базовые аргументы поля¶

Каждый конструктор класса Field принимает эти аргументы. Некоторые классы Field принимают дополнительные аргументы. Перечисленные ниже аргументы принимаются всеми полями:

required ¶

По умолчанию каждый класс Field предполагает значение обязательным. Таким образом, если вы передадите ему пустое значение, т.е. None или пустую строку ( «» ), то метод clean() вызовет исключение ValidationError :

Для того, чтобы сделать поле «необязательным» передайте required=False в конструктор Field :

Widgets of required form fields have the required HTML attribute. Set the Form.use_required_attribute attribute to False to disable it. The required attribute isn’t included on forms of formsets because the browser validation may not be correct when adding and deleting formsets.

label ¶

Аргумент label позволяет вам определить «видимую людьми» метку для этого поля. Оно используется когда Field отображается на форме.

Ниже приведён пример формы, которая определяет метки для двух своих полей. Мы используем auto_id=False для упрощения вывода:

label_suffix ¶

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

initial ¶

Аргумент initial позволяет определять начальное значение для поля, при его отображении на незаполненной форме.

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

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

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

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

Вместо констант вы также можете передавать любой исполняемый объект ( callable ):

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

widget ¶

help_text ¶

Ниже представлен пример формы, в которой help_text определён у двух полей. Мы используем auto_id=False для упрощения вывода:

error_messages ¶

Аргумент error_messages позволяет изменить стандартные сообщения об ошибках, которые выдаёт поле. Создайте словарь с ключами тех сообщений, которые вы желаете изменить. Например, стандартное сообщение об ошибке:

А вот собственное сообщение об ошибке:

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

validators ¶

Аргумент validators позволяет указать список функций, осуществляющих проверку поля.

Обратитесь к документации на валидаторы для подробной информации.

localize ¶

Аргумент localize включает локализацию для данных формы, как на входе, так и на выходе.

See the format localization documentation for more information.

disabled ¶

Устанавливается при изменении данных поля¶

has_changed() ¶

Смотрите документацию на Form.has_changed() для подробностей.

Классы встроенных полей¶

Для каждого поля мы указываем виджет, который используется в случае, если вы явно не определили нужный вам виджет. Мы также указываем значение, которое будет возвращено, если вы предоставили пустое значение (см. required).

BooleanField ¶

CharField ¶

Имеет три необязательных аргумента для проверки:

Если они указаны, то производится соответствующая проверка длины полученной строки.

При True (по умолчанию), у значения будут обрезаны пробелы в начале и в конце.

The value to use to represent «empty». Defaults to an empty string.

ChoiceField ¶

Takes one extra argument:

Either an iterable of 2-tuples to use as choices for this field, or a callable that returns such an iterable. This argument accepts the same formats as the choices argument to a model field. See the model field reference documentation on choices for more details. If the argument is a callable, it is evaluated each time the field’s form is initialized. Defaults to an empty list.

TypedChoiceField ¶

Принимает дополнительные аргументы:

DateField ¶

Принимает один необязательный аргумент:

DateTimeField ¶

Принимает один необязательный аргумент:

DecimalField ¶

Принимает четыре необязательных аргумента:

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

Максимальное число разрешённых десятичных разрядов.

DurationField ¶

EmailField ¶

FileField ¶

Ошибка max_length относится к длине имени файла. В сообщении об ошибке шаблон %(max)d будет заменён максимальной длиной имени файла, а %(length)d – длиной имени текущего файла.

FilePathField ¶

The field allows choosing from files inside a certain directory. It takes five extra arguments; only path is required:

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

Шаблон регулярного выражения. Отображаться будут только те файлы, которые подходят под указанное регулярное выражение.

FloatField ¶

ImageField ¶

Использование ImageField требует наличия Pillow (рекомендуется) с поддержкой используемых вами форматов изображений. Если вы сталкиваетесь с ошибкой corrupt image при загрузке изображения, обычно это означает, что Pillow не поддерживает такой формат изображения. Для решения этой проблемы, установите соответствующую библиотеку и переустановите Pillow.

IntegerField ¶

Принимает два необязательных аргумента для проверки:

Они определяют диапазон значений, разрешённый для поля.

GenericIPAddressField ¶

Поле для обработки адресов IPv4 или IPv6.

Принимает два необязательных аргумента:

MultipleChoiceField ¶

TypedMultipleChoiceField ¶

NullBooleanField ¶

RegexField ¶

Принимает один обязательный аргумент:

Регулярное выражение в виде строки или скомпилированного объекта регулярного выражения.

SlugField ¶

Это поле предназначено для представления поля модели SlugField на формах.

Принимает необязательный аргумент:

TimeField ¶

Принимает один необязательный аргумент:

URLField ¶

Принимает следующие необязательные аргументы:

UUIDField ¶

Достаточно сложные встроенные классы Field ¶

ComboField ¶

Принимает один дополнительный обязательный аргумент:

Список полей, которые должны использоваться для проверки значения поля (в порядке их определения).

MultiValueField ¶

Агрегирует логику нескольких полей, создавая единое значение.

Принимает один дополнительный обязательный аргумент:

Also takes some optional arguments:

Этот метод должен быть реализован в дочерних классах.

SplitDateTimeField ¶

Принимает два необязательных аргумента:

Поля для обработки связей¶

Возможно указать queryset=None при определении поля, далее в конструкторе формы определить значение этого атрибута:

ModelChoiceField ¶

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

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

A QuerySet of model objects from which the choices for the field are derived and which is used to validate the user’s selection. It’s evaluated when the form is rendered.

ModelChoiceField принимает два необязательных аргумента:

Источник