success url django что это
Немного подробностей про Class Based Views, ч.4
Здравствуйте! В продолжении серии статей про Class Based Views (далее CBV) переходим к разделу, посвященному редактированию объектов. В данной статье мы рассмотрим четыре класса с говорящими названиями: FormView, CreateView, UpdateView, DeleteView.
Создание и обработка формы с помощью CBV
Для ряда действий, будь то регистрация или авторизация на сайте, публикация новости, комментария или добавление товара в магазине, невозможно обойтись без форм. В качестве универсального инструмента создания форм в Django выступает класс FormView. В самом просто случае для создания работоспособной формы достаточно лишь передать ему лишь ссылку на класс, описывающий необходимую форму:
или передать нужные данные непосредственно экземпляру класса FormView в нашем urlconf:
Note: Пример синтетический и, разумеется, в таком виде использовать для страницы регистрации не получится.
Класс формы, который необходимо обработать, возвращается методом get_form_class. По умолчанию данный метод возвращает атрибут form_class, которому мы присваивали класс нашей формы в примере выше. Мы можем переопределить данный метод, если нам требуется более сложная логика в определении класса формы.
Метод get_success_url возвращает url ссылку, на которую будет осуществляться переход после успешной обработки формы. По умолчанию данный метод возвращает атрибут success_url.
Для указания полям формы значений по умолчанию мы можем передать их непосредственно в атрибут initial, представляющий из себя словарь, ключи которого должны иметь имена требуемых полей формы. Значение данного атрибута возвращается по умолчанию методом get_initial.
Часто возникает необходимость передать в форму определенные данные, например объект пользователя или заранее определенный список разделов. Для данного действия подходит метод get_form_kwargs. При переопределении данного метода необходимо соблюдать осторожность и не переписать случайно данные, передаваемые в форму по умолчанию. Среди них:
Чтобы избежать потери этих данных мы должны сначала получить словарь из родительского класса, затем добавить в него требуемые данные:
Для получения класса нашей формы мы можем использовать метод get_form, который по умолчанию возвращает класс формы, указанный через метод form_class, с переданным ему словарем метода get_form_kwargs:
При обработке формы, в случае успеха, Django вызывает метод form_valid нашего отображения. По умолчанию данный метод осуществляет редирект по ссылке, возвращаемой методом get_success_url.
В случае, когда форме переданы некорректные данные вызывается метод form_invalid, который по умолчанию возвращает пользователя обратно на страницу формы, передавая ей объект со списком ошибок валидации.
Теперь рассмотрим разные сферы применения форм более подробно.
Создание нового экземпляра объекта
С помощью примера выше мы можем с легкостью создать новый объект статьи, однако в Django есть средства, позволяющие создать объект с еще большей легкостью, это класс CreateView. Для применения данного класса, передаваемая ему форма должна наследоваться от ModelForm:
Теперь мы можем передать объект данной формы в наше отображение. Пример отображения почти аналогичен предыдущему:
Если необходимо провести более сложные действия перед сохранением модели (проставить внешние ключи, добавить дополнительную информацию), то более подходящим способом это сделать будет следующий пример (спасибо пользователю marazmiki):
Note: Определение метода form_valid может быть излишне, так как CreateView наследует ModelFormMixin, который сохраняет экземпляр объекта из формы автоматически.
Для обработки ошибок также используется метод form_invalid, функциональность которого аналогична оной класса FormView.
Обновление экземпляра объекта
Основное отличие класса UpdateView от CreateView, это передача экземпляра изменяемого объекта атрибуту object данного класса, в остальном данные классы идентичны. Для редактирования нам достаточно передать в url первичный ключ или slug изменяемого объекта:
Описание формы и модели для класса CreateView выглядит аналогичным образом.
Удаление экземпляра объекта
Логика отображения для удаления объекта несколько отличается от рассмотренных предыдущих классов в данной статье. Удаление объекта, в целях безопасности, доступно лишь после передачи post или delete запроса. В случае get запроса будет отображена страница с подтверждением удаления объекта. В самом минималистичном варианте она может представлять из себя форму с кнопкой отправки и csrf токеном:
Отображение может выглядеть следующим образом:
Разумеется если вам потребуются соответсвующие проверки на наличие авторизации у пользователей или соответствующих прав, то вы можете сделать это используя декораторы для метода dispatch или добавить свою логику проверки:
В данной статье мы рассмотрели работу с формами и управлением объектами, если у вас возникнут какие-либо вопросы, то я или другие читатели, надеюсь, смогут на них ответить. Также прошу сообщить обо всех найденных ошибках или неточностях и предложения по добавлению информации в статью, если я что-то пропустил. Спасибо, что прочитали статью и желаю счастливых выходных =)
Редактирование классов миксинов ¶
Следующие классы миксинов используются для создания представлений редактирования Django:
FormMixin ¶
Класс миксина, предоставляющий инструменты для создания и отображения форм.
Классы миксинов
Методы и атрибуты
Словарь, содержащий исходные данные формы.
Класс формы, для которого нужно создать экземпляр.
URL-адрес для перенаправления ответа при успешной обработке формы.
Префикс prefix сгенерированной формы.
get_form ( form_class = Нет ) ¶
Создает именованные параметры, необходимые для создания экземпляра формы.
Определяет префикс prefix сгенерированной формы. Возврат prefix по умолчанию.
Определяет URL-адрес для перенаправления после успешной проверки формы. Возврат success_url по умолчанию.
Выдает ответ, помещая недопустимую форму в контекст.
ModelFormMixin ¶
Класс миксина форм, который работает с ModelForms формами, а не с отдельными формами.
Классы миксинов
Методы и атрибуты
URL-адрес для перенаправления ответа при успешной обработке формы.
success_url может содержать строки формата словарного типа, которые будут заменены атрибутами поля объекта. Например, вы можете использовать success_url=»/polls/
Определяет URL-адрес для перенаправления после успешной проверки формы. Возвращает, django.views.generic.edit.ModelFormMixin.success_url если определено; в противном случае попробуйте использовать get_absolute_url() значение объекта.
Выдает ответ, помещая недопустимую форму в контекст.
ProcessFormView ¶
Класс миксина, который обеспечивает обычную обработку потока HTTP-запросов GET и POST.
Расширяет
Методы и атрибуты
Создает форму, проверяет действительность формы и обрабатывает ее соответствующим образом.
DeletionMixin ¶
Методы и атрибуты
URL-адрес для перенаправления после успешного удаления затронутого объекта.
success_url может содержать строки формата словарного типа, которые будут заменены атрибутами поля объекта. Например, вы можете использовать success_url=»/parent/
Возвращает URL-адрес для перенаправления после успешного удаления затронутого объекта. Возврат success_url по умолчанию.
Documentation
Editing mixins¶
The following mixins are used to construct Django’s editing views:
FormMixin ¶
A mixin class that provides facilities for creating and displaying forms.
Mixins
Methods and Attributes
A dictionary containing initial data for the form.
The form class to instantiate.
The URL to redirect to when the form is successfully processed.
The prefix for the generated form.
Build the keyword arguments required to instantiate the form.
Determine the prefix for the generated form. Returns prefix by default.
Determine the URL to redirect to when the form is successfully validated. Returns success_url by default.
Renders a response, providing the invalid form as context.
Calls get_form() and adds the result to the context data with the name ‘form’.
ModelFormMixin ¶
If you specify both the fields and form_class attributes, an ImproperlyConfigured exception will be raised.
Mixins
Methods and Attributes
This is a required attribute if you are generating the form class automatically (e.g. using model ). Omitting this attribute will result in an ImproperlyConfigured exception.
The URL to redirect to when the form is successfully processed.
success_url may contain dictionary string formatting, which will be interpolated against the object’s field attributes. For example, you could use success_url=»/polls/
Determine the URL to redirect to when the form is successfully validated. Returns django.views.generic.edit.ModelFormMixin.success_url if it is provided; otherwise, attempts to use the get_absolute_url() of the object.
Renders a response, providing the invalid form as context.
ProcessFormView ¶
A mixin that provides basic HTTP GET and POST workflow.
Extends
Methods and Attributes
Constructs a form, checks the form for validity, and handles it accordingly.
DeletionMixin ¶
Enables handling of the DELETE http action.
Methods and Attributes
The url to redirect to when the nominated object has been successfully deleted.
success_url may contain dictionary string formatting, which will be interpolated against the object’s field attributes. For example, you could use success_url=»/parent/
Retrieves the target object and calls its delete() method, then redirects to the success URL.
Returns the url to redirect to when the nominated object has been successfully deleted. Returns success_url by default.
Делаем авторизацию пользователей на сайте
На предыдущем занятии мы рассмотрели механизм регистрации пользователей. Продолжим эту тему и поговорим об авторизации пользователей на сайте.
Когда на север приходит запрос от пользователя, то на стороне сайта важно знать авторизован этот пользователь уже или нет. То есть, он мог ранее уже регистрироваться и авторизоваться на сайте, фреймворк Django сохранил эту информацию в сессии и при поступлении очередного запроса от этого же пользователя мы его должны воспринимать как авторизованного:
Если же пользователь не авторизован, то на сайте должен быть реализован механизм авторизации. Обычно, это форма, где пользователь вводит логин и пароль:
Именно этот функционал мы и реализуем на данном занятии. А подробную информацию об авторизации можно почитать на странице русскоязычной документации:
Итак, первым делом добавим в файле views.py класс представления, отвечающий за отображение формы авторизации:
В качестве базового класса используется LoginView, в котором реализована вся необходимая логика работы, а также стандартный класс формы AuthenticationForm. Затем, мы указываем наш шаблон login.html для отображения формы со стандартным содержимым:
Осталось в файле urls.py связать маршрут login с нашим классом представления:
а функцию представления login поставим в комментарии. Все, если теперь перейти в браузер и щелкнуть по ссылке «Войти», то увидим стандартную форму авторизации. Причем, она уже работает. Давайте введем «user1», пароль и при нажатии на кнопку «Войти» происходит авторизация пользователя и делается автоматическое перенаправление в профайл. Нам это не нужно. Изменим адрес перенаправления, переопределив метод get_success_url() в классе LoginUser:
Теперь, при авторизации будем попадать на главную страницу. Этот же эффект можно получить, определив константу:
в файле settings.py пакета конфигурации coolsite.
Следующим шагом улучшим отображение формы авторизации. Для этого в файле forms.py пропишем класс LoginUserForm, унаследовав его от базового AuthenticationForm:
И, затем, укажем его в классе представления LoginUser:
Также в шаблоне login.html сделаем вывод полей через цикл:
Обратите внимание, вначале не забываем делать отображение общих ошибок коллекции form.non_field_errors. Теперь форма выглядит гораздо лучше.
Следующим шагом, авторизованным пользователям вместо ссылок «Регистрация» и «Войти» будем показывать ссылку «Выйти». Для этого, в шаблоне base.html, добавим следующую проверку:
Здесь используется объект request, через него обращаемся к объекту user и уже у этого объекта проверяем свойство is_authenticated. Если оно принимает значение True, значит, пользователь авторизован, иначе – не авторизован. Для авторизованных пользователей отображается ссылка «Выйти» с именем маршрута logout. Пропишем его в файле urls.py:
Если теперь обновить страницу сайта, то увидим эту ссылку «Выйти». Создадим для нее функцию представления, так как непосредственного отображения страницы она не предполагает. Эта функция будет иметь вид:
Мы здесь используем стандартную функцию logout() фреймворка Django для выхода пользователя. А, затем, перенаправляем его на форму авторизации.
В принципе, в базовом варианте авторизация готова. Но мы сделаем еще одно улучшение. При успешной регистрации пользователя будем автоматически его авторизовывать, что, мне кажется логичным действием. Для этого, в классе RegisterUser переопределим специальный метод form_valid():
Он отрабатывает при успешной проверки формы регистрации, а значит, при успешной регистрации. Здесь мы самостоятельно сохраняем форму (добавляем пользователя в БД), а затем, вызываем функцию фреймворка Django login для авторизации пользователя. После этого, делаем перенаправление на главную страницу.
Давайте посмотрим как это будет работать. Откроем форму регистрации, заполним поля и, нажимая на кнопку «Регистрация», попадаем на главную страницу. В главном меню рядом со ссылкой «Выйти» видим имя только что зарегистрированного пользователя, следовательно, мы вошли именно под ним.
Вот так, довольно просто в Django можно выполнять авторизацию пользователей на сайте.
Видео по теме
#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 Частичное или полное копирование информации с данного сайта для распространения на других ресурсах, в том числе и бумажных, строго запрещено. Все тексты и изображения являются собственностью сайта
Documentation
Form handling with class-based views¶
Form processing generally has 3 paths:
Implementing this yourself often results in a lot of repeated boilerplate code (see Using a form in a view ). To help avoid this, Django provides a collection of generic class-based views for form processing.
Basic forms¶
Given a contact form:
The view can be constructed using a FormView :
Model forms¶
Model form views provide a form_valid() implementation that saves the model automatically. You can override this if you have any special requirements; see below for examples.
If you want to use a custom ModelForm (for instance to add extra validation), set form_class on your view.
First we need to add get_absolute_url() to our Author class:
Then we can use CreateView and friends to do the actual work. Notice how we’re just configuring the generic class-based views here; we don’t have to write any logic ourselves:
If you specify both the fields and form_class attributes, an ImproperlyConfigured exception will be raised.
Finally, we hook these new views into the URLconf:
These views inherit SingleObjectTemplateResponseMixin which uses template_name_suffix to construct the template_name based on the model.
Models and request.user ¶
In the view, ensure that you don’t include created_by in the list of fields to edit, and override form_valid() to add the user:
Content negotiation example¶
Here is an example showing how you might go about implementing a form that works with an API-based workflow as well as ‘normal’ form POSTs: