В конце этой статьи я надеюсь, что вы сможете понять разницу между представлением на основе функций и представлением на основе классов, а также когда их использовать.
Я буду использовать приложение для списка дел, чтобы объяснить обе терминологии. Это будет часть I из трех частей серии, в этой части я объясню разницу между представлением на основе функций и представлением на основе классов, а в части II мы будем строить логику (представления) приложения для списка дел, используя представления на основе функций; в этой части я явно проведу вас через основы представления на основе функций, а в последнем эпизоде часть III то же приложение, те же функции, но на этот раз с использованием представления на основе классов.
С учетом сказанного, давайте погрузимся в работу.
ЧАСТЬ I
Представления Django — это место, где пишется логика приложения, и у нас есть два основных способа (представление на основе функций и представление на основе классов) сделать это, которые мы рассмотрим в этой статье.
Представление на основе функций, как следует из названия, это представление, создаваемое встроенными функциями Django, использование представления на основе функций показывает рабочие части каждого метода в вашем Django приложении, оно показывает, как работают все аспекты вашего кода, если вы начинаете работать с Django, я настоятельно рекомендую вам начать с представлений на основе функций, так как вы увидите и поймете логику, происходящую под капотом, хотя это требует больше строк кода, но это облегчает понимание того, что происходит и что именно представляет каждая строка кода.
Одной из отличительных особенностей между представлением на основе классов и представлением на основе функций является обработка HTTP-ответов. В представлении на основе функций активно используются логические операторы с условиями, поскольку все запросы записываются в одну функцию, а в представлении на основе классов мы можем разделить эти запросы на различные функции, и все они остаются внутри класса.
Помните, что представления на основе классов не заменяют представления на основе функций, оба представления уникальны в своих способах решения конкретных проблем, так как не все алгоритмы требуют подхода на основе классов и наоборот, выбор того или другого зависит от того, что вы строите и как вы собираетесь это делать.
Следует помнить, что все функции, как в представлении на основе классов, так и в представлении на основе функций, должны быть:
- Вызываемыми
- Принимать HTTP-запрос
- Возвращать HTTP-запрос
Прежде чем мы начнем создавать наше приложение для создания списка дел, как необходимое условие для получения максимальной пользы от этой статьи, вы должны иметь рабочее понимание Django и как создать проект в Django, как начать Django приложение, как работают Django модели, а также базовое понимание Django представлений, шаблонов и маршрутизации URL.
ЧАСТЬ II
Kanyi — это очень простое в использовании приложение для составления списка дел с функциями CRUD, входа/выхода пользователей, регистрации, аутентификации и авторизации пользователей, а также функциями поиска.
Kanyi был построен с использованием базового HTML, CSS и Django, используя модель представления на основе функций, я объясню некоторые из этих терминов.
Я ожидаю, что у вас уже должен быть запущен проект и установлено приложение с костюмом.
МОДЕЛИ ДЖАНГО
Создайте модель django под названием Task в models.py.
Строка 6; мы определяем модель с именем Task
Строки 7-11; представляют собой различные поля, с которыми будет взаимодействовать наш внешний пользователь
Строка 7; устанавливает связь один ко многим с нашей моделью Task, используя модель ForeignKey; Django поставляется с таким количеством встроенных функций, классов и атрибутов, модель User по умолчанию уже создана для нас, чтобы иметь возможность использовать ее, мы должны сначала импортировать ее в строке 2.
Объяснение отношения один-ко-многим
Один пользователь, имеющий несколько задач, является примером отношения «один-ко-многим».
on_delete = models.CASCADE
Указание базе данных удалить все задачи, созданные пользователем, если пользователь удален
Строка 8; title — это charfield, который по умолчанию должен иметь заданную max_length
null=True означает, что в базе данных может существовать пустое поле
blank=True означает, что пустое поле может быть представлено.
Строка 10; принимает булево значение и его значение по умолчанию устанавливается в false
Строка 11; создает метку времени каждый раз, когда создается задача, это автоматизировано с помощью атрибута auto_add_now = True.
Класс Meta описывает поведение поля вашей модели, например, как отображаются данные.
Мы намеренно пропустили основы создания проекта и приложения Django, чтобы мы могли сосредоточиться на цели этой статьи.
ВИДЫ ДЖАНГО
Теперь мы переходим к views.py
где мы создаем наши представления на основе функций, views.py имеет дело с логикой вашего Django приложения.
Мы создаем функцию представления для каждой из наших CRUD-функций, т.е. функцию представления для создания, чтения, обновления, удаления (CRUD) задач.
Мы начнем с функции чтения под названием tasklist
@login_required — это декоратор Django, который ограничивает доступ к этой функции приложения только аутентифицированным (вошедшим в систему) пользователям, обычно мы добавляем его почти ко всем функциям.
Что такое декоратор?
Декоратор ограничивает доступ к представлениям на основе аутентификации
Разница между декоратором и миксином
Декоратор добавляет новую функцию к объекту, не изменяя другие экземпляры объектов того же класса.
Миксин наследуется от нескольких родительских классов.
Каждая функция Django должна принимать запрос (POST или GET), а также возвращать запрос.
В строке 110; мы хотим получить все объекты (задачи) из нашей модели Task, мы фильтруем модель Task по пользователю, который создал задачи.
В строке 111; теперь мы получили Users задач, мы хотим фильтровать его дальше по тому, сколько задач было выполнено этим пользователем и подсчитать их.
В строке 112 включена функция поиска; мы получаем введенное поисковое слово с помощью request.GET.get('search_input').
Две основные функции могут быть выполнены в нашей функции списка задач
- Пользователь может выполнить поиск в форме поиска
- Пользователь может просмотреть все свои задачи.
Итак, если пользователь выполняет поиск, мы хотим отфильтровать поиск на этот раз из модели задач по аутентифицированному пользователю и названию задачи title__icontains=search_input в противном случае просто отобразить все задачи пользователя.
Мы используем контекстный словарь для объектов, которые мы собираемся использовать с нашим шаблонизатором.
Как я уже говорил ранее, каждая функция Django принимает запрос и возвращает его.
функция представления taskdetail
Принимает request(POST) и PrimaryKey (уникальный идентификатор).
По умолчанию для каждой созданной задачи также создается уникальный идентификатор, мы получаем доступ к нему, используя PrimaryKey; по умолчанию для каждой модели, созданной в Django, Django также создает уникальный идентификатор, поэтому каждый созданный элемент имеет уникальный идентификатор, мы используем переменную pk для доступа к уникальным идентификаторам, так что в двух словах первая строка принимает запрос(get) и уникальный идентификатор(pk).
остальные строки кода повторяют уже описанные выше коды.
функция просмотра taskedit
Чтобы построить функцию обновления/редактирования, используя представления Django, основанные на функциях, мы используем предварительно созданную форму ModelForm (не обязательно), это вопрос выбора.
ФОРМА ДЖАНГО
Django ModelForm используется для прямого преобразования модели в Django форму
forms.py
TaskEdit наследует все крутые вещи, которые дает нам Django ModelForm model = Task модель, с которой мы будем работать, с этой формой
fields = ['title', 'description', 'completed'] конкретные поля, которые будут отображаться в нашей форме во фронтенде или в качестве альтернативы мы можем выбрать отображение всех полей с помощью fields = '__all__'.
Импортируйте форму TaskEdit в ваш views.py.
Если метод запроса post, мы хотим передать запрос пользователя и экземпляр задачи.
Если форма действительна, сохраните ее и перенаправьте пользователя обратно на главную страницу, указав, что задача была успешно обновлена.
Вопрос: что такое валидная форма в Django?
Django предоставляет встроенные проверки для проверки данных в форме, одной из таких проверок является наличие CSRF токена в методе request.POST. Функция is_valid() используется для чистой и простой проверки каждых данных.
Функция удаления представления
Функция удаления представления в Django довольно проста и понятна, получите конкретную задачу для удаления через ее уникальный идентификатор (PrimaryKey)
используйте функцию Django delete() для удаления задачи.
Создание функции представления
Чтобы построить функцию создания представления, на этот раз мы не будем использовать готовый ModelForm от Django, а создадим свою, используя базовый HTML.
Я просто хочу, чтобы читатель этой статьи ознакомился с различными возможностями, которые мы имеем при создании крутых вещей с помощью Django.
Мы передаем title и description задачи, которая уже была создана с помощью HTML в нашем фронт-энде.
Вызываем функцию .create(), которая создает объект в Django, в него вводится атрибут аутентифицированного пользователя, название задачи и описание, задача сохраняется, а пользователь перенаправляется на главную страницу, чтобы сообщить об успешном создании задачи.
АВТЕНТИФИКАЦИЯ и АВТОРИЗАЦИЯ
Прежде чем мы построим функциональность входа/выхода и регистрации, небольшое введение в разницу между аутентификацией и авторизацией в Django.
Система аутентификации Django обрабатывает как аутентификацию, так и авторизацию.
Аутентификация проверяет утверждения пользователя, а авторизация определяет, что может делать аутентифицированный пользователь.
Мне нужно было объяснить это, некоторые Django dev аутентифицируют пользователя, используя auth.authenticate() другие просто используют .authenticate().
Функция просмотра входа в систему
Наши регистрация и вход в систему используют один и тот же шаблон login-register.html, используя шаблонизатор Django, если страница настроена на вход, мы отображаем форму входа, в противном случае — форму регистрации.
После того, как пользователь уже прошел аутентификацию (вошел в систему), мы хотим сделать так, чтобы он не смог снова попасть на страницу входа.
Получаем имя пользователя и пароль из нашей фронтальной HTML-формы, очищаем данные, добавляя функцию .lower(), чтобы сделать нашу функцию входа не чувствительной к регистру.
Аутентифицируем этого пользователя в переменной с именем user.
Если пользователь существует, мы используем функцию Django login(), которая принимает запрос и пользователя.
В противном случае выводим сообщение об ошибке, если пользователь не существует
Функция представления выхода из системы
Это представление обычно не поставляется с шаблоном для рендеринга, оно очень простое, поскольку использует функцию Django .logout().
Мы просто включаем ее в наш urls.py.
Наконец, мы создаем нашу функцию регистрации, используя UserCreationForm от Django.
Нет необходимости в модификации, как мы сделали с нашей ModelForm, нам нужны все функциональные возможности этой формы.
Передаем пост запроса, если форма валидна, мы выполняем ложное сохранение, чтобы очистить наши данные снова, чтобы убедиться, что они не чувствительны к регистру, сохраняем пользователя после, иначе, если форма не валидна, выводим ошибку.
Примечание:
Мы можем выполнить оператор else, который позаботится о недействительных паролях, т.е. если пароли не одинаковые, или оператор else, который обработает сообщения об ошибках для недействительного адреса электронной почты, но для целей этого руководства давайте просто придерживаться одного сообщения об ошибке для всех ошибок, с которыми может столкнуться неаутентифицированный пользователь.
Функция ОС в Django
В Django есть специальная функция, называемая модулем OS. Этот модуль предоставляет функции для создания или удаления каталога, получения его содержимого, изменения и идентификации текущего каталога.
Ниже приведена репозитория GitHub для полного проекта.
GitHub repo
Ниже приведена ссылка на то, где был развернут этот проект.
Kanyi