необязательное поле модели django
Необязательное поле модели 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 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» поле даты публикации можно оставлять пустым.
Модели ¶
Быстрый пример ¶
Этот образец шаблона определяет человека ( Person ) с именем ( first_name ) и фамилией ( last_name ):
first_name и last_name являются полями модели. Каждое поле определяется как атрибут класса, и каждый атрибут соответствует столбцу базы данных.
Приведенный Person выше шаблон создаст такую таблицу базы данных:
Некоторые технические примечания:
Использование моделей ¶
Например, если ваша модель приложения находится в модуле myapp.models (структура пакета, созданная для приложения скриптом ), должна содержать: manage.py startapp INSTALLED_APPS
Типы полей ¶
Параметры поля ¶
Каждое поле принимает ряд определенных параметров (задокументированных в справочнике по полям шаблона ). Например, CharField (и его подклассы) требуется параметр, max_length указывающий размер поля базы данных, в VARCHAR котором будут храниться данные.
Список вариантов выглядит так:
Вы также можете использовать классы перечисления для choices краткого определения
default Значение поля по умолчанию. Это может быть значение или исполняемый объект. В последнем случае объект вызывается каждый раз, когда создается новый объект. help_text Дополнительный текст справки для отображения вместе с компонентом формы. Полезно для документации, даже если поле не используется в форме. primary_key
Поле первичного ключа доступно только для чтения. Если вы измените значение первичного ключа существующего объекта и сохраните его, новый объект будет создан параллельно старому. Например :
Автоматические поля первичного ключа ¶
По умолчанию Django добавляет в каждый шаблон следующее поле:
Это первичный ключ с автоматическим увеличением.
Для каждой модели обязательно иметь одно и только одно поле с параметром primary_key=True (независимо от того, объявлено ли оно явно или добавлено автоматически).
Подробные имена полей ¶
В этом примере подробное имя : «person’s first name»
В этом примере подробное имя : «first name»
Отношения ¶
Ясно, что мощь реляционных баз данных проявляется в ссылках на таблицы. Django предоставляет методы для определения трех наиболее распространенных типов отношений: многие-к-одному, многие-ко-многим и один-к-одному.
Отношения многие-к-одному ¶
ForeignKey требуется позиционный параметр: класс, с которым связана модель.
Предлагается, но не обязательно, чтобы имя ForeignKey поля ( manufacturer в приведенном выше примере) было именем модели в нижнем регистре. Вы можете называть поле как хотите. Например:
Отношения многие-ко-многим ¶
ManyToManyField требуется позиционный параметр: класс, с которым связана модель.
Например, если у одного Pizza есть несколько объектов Topping (топпинг), то есть один Topping может быть на нескольких пиццах, и у каждого Pizza есть несколько начинок, это будет представлено следующим образом:
Рекомендуется, но не обязательно, чтобы имя поля ManyToManyField ( toppings в приведенном выше примере) было множественным числом, описывающим все связанные объекты модели.
Дополнительные поля в отношениях «многие ко многим» ¶
Когда вам приходится иметь дело с отношениями « многие ко многим », такими как смешивание и комбинирование пиццы и начинки, достаточно одного ManyToManyField стандарта. Однако иногда необходимо связать данные с отношениями между двумя моделями.
В таких ситуациях Django позволяет указать шаблон, который будет использоваться для определения отношения «многие ко многим». Затем можно определить дополнительные поля в промежуточной модели. Последний связан с полем ManyToManyField с помощью параметра, through который будет указывать на модель, действующую в качестве посредника. В нашем музыкальном примере код может выглядеть так:
Когда вы определяете промежуточную модель, вы явно указываете внешние ключи для моделей, участвующих в отношении «многие ко многим». Это явное заявление определяет, как связаны две модели.
На модель среднего размера есть несколько ограничений:
После настройки поля ManyToManyField для использования промежуточного шаблона ( Membership в данном случае) вы готовы приступить к построению отношений «многие ко многим». Это делается путем создания экземпляров промежуточной модели:
Может быть предпочтительнее создавать экземпляры промежуточной модели напрямую.
Этот метод clear() можно использовать для удаления всех отношений «многие ко многим» из экземпляра.
После установления отношений «многие ко многим» можно выполнять запросы. Как и в случае обычного отношения «многие ко многим», запросы могут использовать атрибуты модели, связанные с отношением «многие ко многим»:
Поскольку вы используете промежуточную модель, запрос также может использовать ее атрибуты:
Если вам нужно получить доступ к информации о членстве в группе, вы можете сделать это, напрямую запросив модель Membership :
Отношения один на один ¶
OneToOneField требуется позиционный параметр: класс, с которым связана модель.
Шаблоны в нескольких файлах ¶
Совершенно приемлемо связать модель с моделью другого приложения. Для этого импортируйте модель и сделайте ссылку на верхнюю часть файла, в котором определена ваша модель. Затем при необходимости обратитесь к этому другому классу модели. Например :
Ограничения на имена полей ¶
Django имеет некоторые ограничения на имена полей модели:
Имя поля не может быть зарезервированным словом Python, так как это приведет к синтаксической ошибке Python. Например :
Имя поля не может содержать два завершающих символа подчеркивания из-за того, как синтаксис Django работает с запросами. Например :
Имя поля не может заканчиваться знаком подчеркивания по аналогичным причинам.
Типы настраиваемых полей ¶
¶ варианты Meta
Атрибуты модели ¶
Модельные методы ¶
Чтобы добавить к своим объектам функциональность «на уровне строк», определите в модели пользовательские методы. В то время как методы Manager предназначены для работы на уровне таблицы, методы моделей действуют скорее на конкретный экземпляр модели.
Например, в этой модели есть несколько пользовательских методов:
«Магический метод» Python, который возвращает текстовое представление объекта. Это то, что Python и Django используют всякий раз, когда экземпляр модели необходимо преобразовать в простую строку для отображения. Это, например, случай, когда объект должен отображаться в интерактивной консоли или в интерфейсе администрирования.
Этот метод всегда следует определять; значение по умолчанию действительно не очень полезно.
Этот метод сообщает Django, как создать URL-адрес для объекта. Django использует его в своем интерфейсе администратора, а также всякий раз, когда ему нужно знать URL-адрес объекта.
Каждый объект с уникальным идентификатором URL должен определять этот метод.
Перегрузка предопределенных шаблонных методов ¶
Вы можете переопределить эти методы (и любой другой метод шаблона), чтобы изменить их поведение.
Вы также можете запретить запись:
Важно не забыть вызвать метод родительского класса (это его дело ), чтобы убедиться, что объект зарегистрирован в базе данных. Если вы не можете вызвать родительский метод, поведение по умолчанию не применяется и база данных не пострадает. super().save(*args, **kwargs)
Перегруженные методы модели не вызываются в сгруппированных операциях
Запуск собственного SQL ¶
Наследование модели ¶
В Django возможно три типа наследования.
Абстрактные базовые классы ¶
Во многих ситуациях уместен именно этот тип наследования модели. Он предлагает возможность группировки общей информации на уровне Python при создании только одной таблицы базы данных для каждой дочерней модели.
Наследование от Meta ¶
У некоторых атрибутов нет веских причин для включения в класс Meta абстрактного базового класса. Например, наличие будет db_table означать, что все дочерние классы (те, которые не содержат свой собственный класс Meta ) будут использовать одну и ту же таблицу базы данных, что определенно не будет желаемым поведением.
Из-за того, как работает наследование Python, если дочерний класс наследуется от нескольких абстрактных базовых классов, по умолчанию будут наследоваться только параметры Meta из первого перечисленного класса. Чтобы наследовать Meta- параметры от нескольких абстрактных базовых классов, вы должны явно объявить Meta- наследование. Например:
Будьте осторожны с related_name и related_query_name ¶
Например, для данного приложения common/models.py :
В сопровождении другого приложения rare/models.py :
Многотабличное наследование ¶
OneToOneField Автоматически созданное поле, к Restaurant которому он привязан, Place выглядит так:
Meta и многотабличное наследование ¶
Таким образом, дочерняя модель не имеет доступа к мета- классу своего родителя. Однако есть несколько ограниченных случаев, когда дочерний элемент наследует поведение от своего родителя: если дочерний элемент не указывает атрибут ordering или get_latest_by он наследует соответствующие атрибуты от своего родителя.
Если у родителя есть порядок сортировки, но вы не хотите, чтобы у дочернего элемента был какой-либо порядок сортировки, вы можете явно отключить его:
Наследование и обратные отношения ¶
Например, все еще основанный на классе Place выше, давайте создадим еще один подкласс с полем ManyToManyField :
Это приводит к ошибке:
Указание ссылки на родительское поле ¶
Как уже упоминалось, Django автоматически создает отношение OneToOneField дочернего класса к любой неабстрактной родительской модели. Если вы хотите контролировать имя ссылки на родительское поле, вы можете добавить свое собственное поле OneToOneField и parent_link=True указать, что это поле является полем ссылки на родительский класс.
Прокси-модели ¶
При использовании наследования нескольких таблиц новая таблица базы данных создается для каждого подкласса модели. Обычно это желаемое поведение, поскольку подкласс должен иметь возможность хранить дополнительные поля данных, которых нет в базовом классе. Однако в некоторых случаях необходимо изменить только поведение модели на языке Python, например, чтобы изменить обработчик по умолчанию или добавить новый метод.
Это цель наследования прокси-модели: создать прокси для исходной модели. Вы можете создавать, удалять и обновлять экземпляры прокси-модели, и все данные будут сохранены, как если бы вы использовали исходную (не прокси) модель. Разница в том, что вы можете изменить некоторые вещи в шаблоне прокси, такие как сортировка шаблонов по умолчанию или обработчик по умолчанию, без необходимости касаться исходного шаблона.
Запросы QuerySet всегда возвращают запрошенную модель ¶
Ограничения базового класса ¶
Прокси-модель может наследовать только один неабстрактный класс модели. Невозможно наследовать от нескольких неабстрактных моделей, потому что прокси-модель не обеспечивает никакого соединения между строками разных таблиц базы данных. Прокси-модель может наследовать столько классов абстрактных моделей, сколько необходимо, если они не определяют поле модели. Прокси-модель также может наследовать от нескольких других прокси-моделей, которые имеют общий неабстрактный родительский класс.
Менеджеры прокси-моделей ¶
Если вы не укажете обработчик модели для прокси-модели, она наследует обработчики от своих родительских моделей. Если вы определяете менеджера в модели прокси, он становится менеджером по умолчанию, хотя любые менеджеры, определенные в родительских классах, также будут доступны.
Продолжая приведенный выше пример, вы можете изменить обработчик по умолчанию, используемый при запросе модели, Person следующим образом:
Если вы хотите добавить новый обработчик в модель прокси, не заменяя тот, который используется по умолчанию, вы можете использовать методы, описанные в документации по настраиваемым обработчикам : создать базовый класс, содержащий новые обработчики, и наследовать от него после класса основная база:
Это достаточно редко, но при необходимости это возможно.
Различия между наследованием прокси и неуправляемыми моделями ¶
Наследование от прокси-моделей внешне очень похоже на создание неуправляемых моделей с использованием атрибута managed класса Meta модели.
При тщательном определении Meta.db_table можно создать непилотируемую модель, скрывающую существующую модель и добавляющую к ней методы Python. Однако это решение очень повторяющееся и хрупкое, поскольку в случае модификаций необходимо вручную синхронизировать их.
С другой стороны, прокси-модели спроектированы так, чтобы вести себя точно так же, как модель, которую они расширяют. Они всегда синхронизируются с родительской моделью, потому что напрямую наследуют ее поля и менеджеров.
Общие правила таковы:
Множественное наследование ¶
Обратите внимание, что наследование от нескольких моделей, которые имеют id общее поле первичного ключа, приведет к ошибке. Для правильного множественного наследования вы можете использовать AutoField явное поле в базовых моделях:
Маскирование имени поля не допускается ¶
Эти дополнительные атрибуты нельзя заменить без изменения или удаления поля, в котором они определены, так, чтобы оно больше не определяло эти атрибуты.
Перегрузка полей родительской модели вызывает проблемы в областях инициализации новых экземпляров (чтобы указать, какое поле инициализируется Model.__init__ ) и сериализации. Это ситуации, которые не влияют на наследование обычных классов Python таким же образом, поэтому это различие между наследованием классов Python и наследованием моделей Django не является произвольным.
Django сообщает об ошибке, FieldError если вы переопределяете поле шаблона родительского класса.
Организация моделей в пакеты ¶
Например, если у вас есть organic.py и synthetic.py в каталоге models :
Справочник моделей Документирует все API-интерфейсы, связанные с моделями, включая поля модели, связанные объекты и запросы ( QuerySet ).
Документация Django 1.9
При создании класса Form наиболее важной деталью является определение полей формы. Каждое поле обладает собственной логикой проверки вводимых данных наряду с дополнительными возможностями.
Базовые аргументы поля¶
Каждый конструктор класса Field принимает эти аргументы. Некоторые классы Field принимают дополнительные аргументы. Перечисленные ниже аргументы принимаются всеми полями:
required ¶
По умолчанию каждый класс Field предполагает значение обязательным. Таким образом, если вы передадите ему пустое значение, т.е. None или пустую строку ( «» ), то метод clean() вызовет исключение ValidationError :
Для того, чтобы сделать поле “необязательным” передайте required=False в конструктор Field :
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 включает локализацию для данных формы, как на входе, так и на выходе.
Обратитесь к документации на формат локализации для подробной информации.
disabled ¶
Устанавливается при изменении данных поля¶
has_changed() ¶
Смотрите документацию на Form.has_changed() для подробностей.
Классы встроенных полей¶
Для каждого поля мы указываем виджет, который используется в случае, если вы явно не определили нужный вам виджет. Мы также указываем значение, которое будет возвращено, если вы предоставили пустое значение (см. required).
BooleanField ¶
Возвращает: True или False языка Python.
CharField ¶
Пустое значение: » (пустая строка).
Возвращает: Объект Unicode.
Имеет три необязательных аргумента для проверки:
Если они указаны, то производится соответствующая проверка длины полученной строки.
При True (по умолчанию), у значения будут обрезаны пробелы в начале и в конце.
ChoiceField ¶
Пустое значение: » (пустая строка).
Возвращает: Объект Unicode.
Проверяет, что введённое значение присутствует в списке вариантов.
Принимает один дополнительный обязательный аргумент:
Итерируемый объект (т.е. список или кортеж), содержащий ряд двухэлементных кортежей, для использования в качестве вариантов для данного поля, или вызываемый объект, который возвращает такой итерируемый объект. Этот аргумент принимает те же форматы, что и аргумент choices поля модели. Обратитесь к справочнику по полям модели для подробной информации. Если в качестве аргумента используется вызываемый объект, он вычисляется при каждой инициализации поля формы.
TypedChoiceField ¶
Проверяет, что полученное значение присутствует в списке вариантов и может быть преобразовано в нужный тип.
Принимает дополнительные аргументы:
DateField ¶
Возвращает: Объект datetime.date языка Python.
Принимает один необязательный аргумент:
Если аргумент input_formats не предоставлен, то используются следующие форматы:
Дополнительно, если вы указали USE_L10N=False в конфигурации проекта, следующее будет включено в список форматов по умолчанию:
Обратитесь к документации на формат локализации для подробной информации.
DateTimeField ¶
Возвращает: Объект datetime.datetime языка Python.
Принимает один необязательный аргумент:
Если аргумент input_formats не предоставлен, то используются следующие форматы:
Обратитесь к документации на формат локализации для подробной информации.
DecimalField ¶
Возвращает: Тип decimal языка Python.
Проверяет, что полученное значение является десятичным. Пробелы до и после значения игнорируются.
Принимает четыре необязательных аргумента:
Максимальное число разрядов (до и после десятичной точки, впередистоящие нули обрезаются) разрешённых в значении.
Максимальное число разрешённых десятичных разрядов.
DurationField ¶
EmailField ¶
Пустое значение: » (пустая строка).
Возвращает: Объект Unicode.
Проверяет, что полученное значение является правильным адресом электронной почты, используя достаточно сложное регулярное выражение.
FileField ¶
Может проверять, что данные непустого файла были связаны с формой.
Для получения подробностей об объекте « UploadedFile`, см. документацию по загрузке файлов.
Ошибка max_length относится к длине имени файла. В сообщении об ошибке шаблон %(max)d будет заменён максимальной длиной имени файла, а %(length)d – длиной имени текущего файла.
FilePathField ¶
Возвращает: Объект Unicode.
Проверяет, что выбранное значение присутствует в списке вариантов.
Поле позволяет выбирать файл из определённого каталога. Оно принимает три дополнительных аргумента, требуя обязательного наличия аргумента path :
Абсолютный путь до каталога, содержимое которого вы желаете отобразить. Этот каталог должен существовать.
Шаблон регулярного выражения. Отображаться будут только те файлы, которые подходят под указанное регулярное выражение.
FloatField ¶
Возвращает: Тип float языка Python.
Проверяет, что полученное значение является числом с плавающей точкой. Пробелы до и после значения не влияют на преобразование значения, так как эта ситуация обрабатывается функцией float() языка Python.
ImageField ¶
Проверяет, что данные файла были связаны с формой, а затем, что файл является изображением, формат которого поддерживается библиотекой Pillow.
Использование ImageField требует наличия Pillow (рекомендуется) с поддержкой используемых вами форматов изображений. Если вы сталкиваетесь с ошибкой corrupt image при загрузке изображения, обычно это означает, что Pillow не поддерживает такой формат изображения. Для решения этой проблемы, установите соответствующую библиотеку и переустановите Pillow.
IntegerField ¶
Возвращает: Тип integer или long языка Python.
Проверяет, что полученное значение является целым числом. Пробелы до и после значения не влияют на преобразование значения, так как эта ситуация обрабатывается функцией int() языка Python.
Принимает два необязательных аргумента для проверки:
Они определяют диапазон значений, разрешённый для поля.
GenericIPAddressField ¶
Поле для обработки адресов IPv4 или IPv6.
Пустое значение: » (пустая строка).
Возвращает: Объект Unicode. Преобразование IPv6 адресов описано далее.
Проверяет, что полученное значение является правильным IP адресом.
Принимает два необязательных аргумента:
MultipleChoiceField ¶
Пустое значение: [] (пустой список).
Возвращает: Список объектов Unicode.
Проверяет, что каждое значение из полученного списка присутствует в списке вариантов.
TypedMultipleChoiceField ¶
Проверяет, что полученные значения присутствуют в списке вариантов и могут быть преобразованы в нужный тип.
NullBooleanField ¶
RegexField ¶
Пустое значение: » (пустая строка).
Возвращает: Объект Unicode.
Проверяет, что полученное значение совпадает с указанным регулярным выражением.
Принимает один обязательный аргумент:
Регулярное выражение в виде строки или скомпилированного объекта регулярного выражения.
SlugField ¶
Пустое значение: » (пустая строка).
Возвращает: Объект Unicode.
Проверяет, что полученное значение содержит только буквы, цифры, подчёркивания и тире.
Это поле предназначено для представления поля модели SlugField на формах.
Принимает необязательный аргумент:
TimeField ¶
Возвращает: Объект datetime.time языка Python.
Проверяет, что переданное значение является объектом datetime.time или строкой, отформатированной в нужном виде.
Принимает один необязательный аргумент:
Если аргумент input_formats не предоставлен, то используются следующие форматы:
URLField ¶
Пустое значение: » (пустая строка).
Возвращает: Объект Unicode.
Проверяет, что полученное значение является правильным URL.
Принимает следующие необязательные аргументы:
UUIDField ¶
Пустое значение: » (пустая строка).
Достаточно сложные встроенные классы Field ¶
ComboField ¶
Пустое значение: » (пустая строка).
Возвращает: Объект Unicode.
Принимает один дополнительный обязательный аргумент:
Список полей, которые должны использоваться для проверки значения поля (в порядке их определения).
MultiValueField ¶
Пустое значение: » (пустая строка).
Агрегирует логику нескольких полей, создавая единое значение.
Принимает один дополнительный обязательный аргумент:
Принимает один необязательный аргумент:
Этот метод должен быть реализован в дочерних классах.
SplitDateTimeField ¶
Стандартный виджет: :class: SplitDateTimeWidget
Возвращает: Объект datetime.datetime языка Python.
Проверяет, что переданное значение является объектом datetime.datetime или строкой, отформатированной в нужном виде.
Принимает два необязательных аргумента:
Поля для обработки связей¶
Возможно указать queryset=None при определении поля, далее в конструкторе формы определить значение этого атрибута:
ModelChoiceField ¶
Возвращает: Экземпляр модели.
Проверяет, что полученный идентификатор присутствует в выборке.
Позволяет выбор единственного объекта модели, имеет смысл при отображении внешнего ключа. Следует отметить, что стандартный виджет для ModelChoiceField становится непрактичным когда число его значений растёт. Сотня значений уже становится проблемой.
Единственный обязательный аргумент:
Объект QuerySet содержит выборку объектов модели, которые являются значениями для этого поля и которые будут использоваться для проверки полученных данных.
ModelChoiceField принимает два необязательных аргумента: