Как сделать уведомления на сайте django

Добавил пользователь Morpheus
Обновлено: 10.09.2024

Джанго — это Open Source фреймворк для создания веб-приложений различной сложности на Python. Одним из его основных преимуществ является то, что вам нужно позаботиться только о логике будущего веб-приложения, остальное сделает Django.

Мы создадим приложение, у которого будет панель администратора и возможность загружать загадки, а у пользователей, соответственно, возможность отвечать на них. Во время разработки будут использоваться Python 3.4.3 и Django 1.9.1.

Устанавливаем Django

Делается это очень просто, в командной строке нужно написать: pip install Django==1.9.1 .

Создаём проект

Если вы правильно установили Django, то после запуска django-admin --version вы увидите текущую версию фреймворка. Теперь создадим проект. Это можно сделать следующим образом: django-admin startproject django_example .

Как только создание проекта будет завершено, взглянем на директорию нашего проекта:

  • django_example/__init__.py — пустой файл, который говорит Python, что данная директория должна восприниматься в качестве пакета.
  • django_example/settings.py содержит конфигурацию нашего проекта.
  • django_example/urls.py — здесь объявляются URL.
  • django_example/wsgi.py — с помощью него приложение может работать с веб-сервером по протоколу WSGI.
  • manage.py позволяет взаимодействовать с проектом.

Пишем веб-приложение на Django

Определим различие между проектом и приложением. Приложение — это программа, которая что-то делает, а проект — это группа приложений.

Итак, приступим к созданию приложения. Это делается следующим образом: python manage.py startapp riddles .
Как только создано веб-приложение, напишем вид, по правилам Джанго все виды должны храниться в файле views.py .

Теперь, чтобы привязать наш вид к URL, создадим файл urls.py .

В urls.py мы должны написать следующее:

Установка базы данных

По умолчанию в Django используется SQLite, если она вас не устраивает, то вы можете ознакомиться с нашей статьей, в которой мы рассказываем, как безболезненно перейти с SQLite на MySQL.

Теперь откроем django_example/settings.py и взглянем на переменную INSTALLED_APPS , она хранит все приложения, которые активны в текущем проекте. По умолчанию она содержит:

Данная модель обеспечивает Django информацией, необходимой для создания схемы базы данных и database-access API для доступа к объектам. Теперь нам нужно привязать наше приложение к нашему проекту, делается это следующим образом:

После этого нужно сделать миграцию: python manage.py makemigrations riddles . Вы должны увидеть следующее:

Так мы говорим Django, что в моделях были сделаны некоторые изменения, и их нужно сохранить в качестве миграции.

Проверить, что сделает миграция, можно так: python manage.py sqlmigrate riddles 0001 (0001 — версия миграции, которую мы хотим проверить). На выходе мы получим:

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

Теперь дадим админу возможность изменять наши модели. Делается это так:

Вот что получится в итоге:

Панель администратора

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

Главная страница

Что нам нужно для создания главной страницы?

  • Templates: скелет нашей страницы.
  • Views: функция на Python для отображения контента.

Начнем с шаблонов. Создадим папку templates внутри папки riddle , а в ней создадим index.html .

Здесь мы используем csrf_token , он нужен для защиты от межсайтовой подделки запроса, каждая внутренняя форма должна его использовать. Теперь напишем виды для рендеринга наших шаблонов:

Давайте пройдемся по каждой функции веб-приложения на Django отдельно:

Теперь добавим наши функции в urls.py :

Стили

Для начала создадим директорию static , а в ней создадим файл main.css .

Немного изменим наши шаблоны:

Теперь вы можете создавать свои веб-приложения на Django. В качестве подсказки на старте работы с фреймворком воспользуйтесь одной из наших шпаргалок по Python.

Исходный код нашего приложения можно скачать по этой ссылке.

Если этот веб-проект на Django показался сложным, попробуйте пройти двухчасовой видеокурс. На нём вы пошагово создадите 3 веб-приложения: сокращатель ссылок, ToDo List и словарь английских слов.

Архив с проектом contact.rar

Первоначальная настройка

Если вы уже знаете как создавать джанго-приложение, этот шаг можно пропустить. Создайте проект — config , приложение — sendemail и виртуальное окружение contact .

Теперь можно установить Django и активировать виртуальную среду.

Примечание:

Есть pipenv у вас не установлен, начните с pip install pipenv

Далее создадим новый проект Django под названием config в приложении sendemail :

Чтобы убедиться, что все работает, запустим migrate и runserver .

Если теперь открыть ссылку 127.0.0.1:8000, то должно появиться приблизительно следующее:

1 ответ 1

Создать модель, новость:

создаём обычную форму с полями, далее в views:

пишем нужный шаблон.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками html django или задайте свой вопрос.

Похожие

Для подписки на ленту скопируйте и вставьте эту ссылку в вашу программу для чтения RSS.

дизайн сайта / логотип © 2022 Stack Exchange Inc; материалы пользователей предоставляются на условиях лицензии cc by-sa. rev 2022.1.28.41306


Обновляем localhost:

Поинтересуйтесь содержимым пунктов меню, там много интересного.

141-я ревизия транка на данный момент, как написано на странице проекта это будущая версия 0.5, совместимая с Django 1.2 (как раз то, что нам нужно). Не забываем requirements.txt (кстати, я подумал, что неплохо было бы сначала добавлять строчку в requirements.txt, а ставить основываясь на файле. Надо только использовать одну директорию с кешом pip, чтобы он постоянно не скачивал дистрибутивы. Ставить установленные приложения по новой он не будет, но мы будем уверены, что не забудем прописать все приложения в requirements.txt и не испытаем проблем на сервере с сайтом).

Документация по настройке. Тут кстати возникает путаница, здесь приложение указано как django_messages, а в документации используется messages, так что используем django_messages.

Скопируем из приложения и изменим под свои нужды.


Пропишем 'django_messages', 'notification' в приложения, настроим url.py. Синхронизируем базу.

Настраиваем. Добавляем css разметку.

А также переведем пару строк, так как в приложении нет русской локализации, djutils\locale\ru_RU\LC_MESSAGES\django.po:
msgid "previous"
msgstr "назад"

msgid "next"
msgstr "вперед"

Не забудем скомпилировать.


В итоге получается:

Чтобы пользователи не были у нас безликими, давайте организуем им вывод профайлов.
В user/url.conf

(блогспот пытается закрыть тег /userprofile_id самостоятельно, конечно это в коде не требуется)
Вид:

Отмечу, что получать надо user, а не наш UserProfile, который еще может быть не создан.

Соответственно, напишем темплейт.


django_messages\templates\notification\ переведите вручную, перевод, который идет с приложением не работает (устарел наверное). Скопируем темплейты в users/templates, создадим папку locale в приложении и запустим создание файла перевода:
>python C:\Python26\Lib\site-packages\django\bin\django-admin.py makemessages -e .html,.txt --locale=ru_RU
в директории users.
После редактирования скомпилируем.

Темлейт для уведомлений notices.html для самостоятельного написания (можно подсмотреть в pinax).

Что такое notification? Это приложение для уведомлений. Когда происходит событие в системе, мы имеем возможность создать уведомление для пользователя, с возможностью настройки дополнительных рассылок уведомлений:

* при логине на сайт.
* по почте (настраивается пользователем).
* по rss

Подключим контекстный процессор "notification.context_processors.notification".

Мне не понравилась часть приложения по работе с url. Поэтому скопировал приложение себе в проект и поправил под свои нужды, получилось примерно следующее:

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

  • Должно произойти мгновенно: request-time операция
  • Должно произойти после ответа: фоновые задачи

Request-time операции могут выполняться в течение одного цикла запрос/ответ, не беспокоясь о том, что операция может получить тайм-аут или что у пользователя может быть плохое соединение. Общие примеры включают CRUD (создание, чтение, обновление, удаление) операций с базой данных и управление пользователями (процедуры входа/выхода).

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

Фоновые задачи являются основным направлением данного руководства. Наиболее распространенным шаблоном программирования, используемым для этого сценария, является Producer-Consumer архитектура.

Проще говоря, эта архитектура может быть описана следующим образом:

  • Producers создают данные или задачи.
  • Задачи помещаются в очередь, которая называется очередью задач.
  • Consumers несут ответственность за потребление данных или выполнение задач.

Обычно сonsumers загружают задачи из очереди в режиме first-out (FIFO) или в соответствии с их приоритетами. Потребителей также называют воркерами, и это термин, который мы будем использовать повсюду, поскольку он согласуется с терминологией, используемой обсуждаемыми технологиями.

Какие задачи можно обрабатывать в фоновом режиме? Задачи, которые:

  • Не являются существенными для основного функционала веб-приложения
  • Не могут выполняться в цикле запросо/ответ, поскольку они медленны (интенсивность ввода-вывода и.т.д.)
  • Зависят от внешних ресурсов, которые могут быть недоступны или не будут вести себя так, как ожидалось
  • Возможно, потребуют повторить попытку хотя бы один раз
  • Должны выполняться по графику

Celery является де-факто выбором для обработки фоновых задач в экосистеме Python/Django. Он имеет простой и понятный API, и он прекрасно сочетается с Django. Он поддерживает различные технологии для очереди задач и различные парадигмы для воркеров.

В этом уроке мы собираемся создать игровое веб-приложение Django (работающее с реальными сценариями), которое использует обработку фоновых задач.

Настройка

Предполагая, что вы уже знакомы с менеджером пакетов Python и виртуальными окружениями, давайте установим Django:

Я решил создать еще одно приложение для ведения блога. Приложение будет простым. Пользователь может просто создать учетную запись и без особых проблем может создать пост и опубликовать его на платформе.

Настройка Django проекта quick_publisher :

Давайте начнем разработку приложения:

При запуске нового Django проекта мне нравится создавать main приложение, которое содержит, помимо прочего, кастомную модель пользователя. Чаще всего Я сталкиваюсь с ограничениями модели User по умолчанию. Наличие пользовательской модели User дает нам гибкость.

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

Теперь нам нужно указать Django, использовать эту модель пользователя вместо стандартной. Добавьте эту строку в файл quick_publisher/settings.py :

Нам также необходимо добавить main приложение в список INSTALLED_APPS в файле quick_publisher/settings.py . Теперь мы можем создавать миграции, применять их и создавать суперпользователя, чтобы иметь возможность входа в панель администратора Django:

Давайте теперь создадим отдельное Django приложение, которое отвечает за посты:

Давайте определим простую модель Post в publisher/models.py :

Привязка модели Post с администратором Django выполняется в файле publisher/admin.py следующим образом:

Наконец, давайте подключим приложение publisher к нашему проекту, добавив его в список INSTALLED_APPS .

Надеюсь, что Вы сделали задание и создали посты.

Давайте двигаться дальше. Следующий очевидный шаг - создать способ просмотра опубликованных постов.

Давайте свяжем наше новое представление с URL-адресом в: quick_publisher/urls.py

Наконец, давайте создадим шаблон, который отображает пост: publisher/templates/post.html

Отправка писем с подтверждением

Вот классический сценарий:

  • Вы создаете учетную запись.
  • Вы указываете адрес электронной почты, который будет идентифицирован, как уникальный на платформе.
  • Платформа проверяет, что вы действительно являетесь владельцем адреса электронной почты, отправив электронное письмо с ссылкой на подтверждение.
  • Пока Вы не выполните проверку, вы не сможете (полностью) использовать платформу.

Давайте добавим флаг is_verified и verify_uid в модель User :

Давайте воспользуемся этим случаем, чтобы добавить возможность администрирования модели User:

Давайте сделаем изменения в базе данных:

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

Сигналы срабатывают до/после определенных событий в приложении. Мы можем определить коллбеки, которые вызываются автоматически при срабатывании сигналов. Чтобы сделать триггер для коллбека, мы должны сначала подключить его к сигналу.

Мы собираемся создать коллбек, который будет вызван после создания пользователя. Мы добавим этот код после определения модели User в: main/models.py

Здесь мы определили функцию user_post_save и связали ее с сигналом post_save (который запускается после сохранения модели), отправленным моделью User .

Django не просто отправляет электронные письма самостоятельно; Его необходимо связать с почтовой службой. Для простоты вы можете добавить свои учетные данные Gmail в quick_publisher/settings.py или добавить своего любимого поставщика электронной почты.

Вот как выглядит конфигурация Gmail:

Чтобы проверить все, зайдите в панель администратора и создайте нового пользователя с действительным адресом электронной почты, который вы можете быстро проверить. Если все пойдет хорошо, вы получите электронное письмо со ссылкой для подтверждения. Процедура проверки еще не готова.

Вот как выполнить проверку учетной записи:

Привязка представления в: quick_publisher/urls.py

Кроме того, не забудьте создать файл home.html в каталоге main/templates/home.html . Это будет рендерится c представлением home .

Попробуйте запустить весь сценарий снова. Если все будет хорошо, вы получите электронное письмо с действительным URL-адресом подтверждения. Если пройдёте по URL-адресу, а затем проверите раздел администратора, Вы увидите, как была проверена учетная запись.

Асинхронная отправка писем

У нас есть проблема в текущей реализации. Возможно, вы заметили, что создание пользователя немного медленное. Это происходит потому, что Django отправляет письмо с проверкой во время запроса.

Вот как это работает: мы отправляем пользовательские данные в приложение Django. Приложение создает модель User , а затем создает соединение с Gmail (или другим выбранным вами сервисом). Django ждет ответа, и только после этого он возвращает ответ на наш браузер.

Вот где проявляется необходимость в Celery. Во первых, убедитесь, что он установлен:

Теперь нам нужно создать Celery приложение в нашем Django приложении:

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

Вы можете установить Redis, следуя инструкциям на странице Redis Quick Start. Вам нужно будет установить библиотеку Redis Python, выполнив pip install redis и комплект, необходимый для использования Redis и Celery: pip install celery [redis] .

Запустите Redis сервер в отдельной консоли следующим образом: $ redis-server

Давайте добавим связанные с Celery/Redis конфиги в quick_publisher/settings.py :

Прежде чем что-либо может быть запущено в Celery, оно должно быть декларировано как задача.

Вот как это сделать:

Мы здесь сделали следующее: мы переместили функцию отправки по почты в другой файл под названием tasks.py .

  • Имя файла имеет значение. Celery проходит через все приложения в INSTALLED_APPS и регистрирует задачи в файлах tasks.py .
  • Обратите внимание, как мы украсили декорировали send_verification_email с помощью @app.task . Это указывает Celery, что это задача, которая будет выполняться в очереди задач.
  • Обратите внимание, что мы ожидаем аргумент user_id , а не объект User . Это связано с тем, что при отправке задач на Celery может возникнуть проблема с сериализацией сложных объектов. Лучше использовать примитивные типы.

Возвращаясь к main/models.py , код сигнала преобразуется в:

Обратите внимание, как мы вызываем метод .delay объекта задачи. Это означает, что мы отправляем задание на Celery, и мы не ожидаем результата. Если бы мы использовали send_verification_email (instance.pk) , мы все равно отправили бы его в Celery и ждали завершения задачи, чего мы не хотим.

Прежде чем Вы начнете создавать нового пользователя, есть есть загвоздка. Celery - это сервис, и нам нужно его запустить. Откройте новую консоль, убедитесь, что вы активируете соответствующий virtualenv, и перейдите в каталог проекта.

Эта команда запустит четыре процесса воркеров Celery. Да, теперь Вы можете, наконец, пойти и создать другого пользователя. Обратите внимание на то, что нет задержки, следите за логами в консоли Celery и посмотрите, правильно ли выполняются задачи. Это должно выглядеть примерно так:

Периодические задачи с Celery

Вот еще один общий сценарий. Большинство зрелых веб-приложений отправляют своим пользователям электронные письма c периодичностью. Некоторые распространенные примеры электронных писем с периодической отправкой:

Как всегда, когда мы меняем модель, нам нужно выполнить миграцию базы данных:

Было бы полезно отобразить view_count в шаблоне. Добавьте

Давайте создадим задачу Celery. Поскольку речь идет о постах, я собираюсь разместить её в publisher/tasks.py :

Каждый раз, когда Вы вносите изменения в задачи Celery, не забудьте перезапустить процесс Celery. Celery должен обнаружить и перезагрузить задачи. Перед созданием задачи выполняющейся периодический мы должны проверить это в Django shell, чтобы убедиться, что все работает как ожидается:

Надеюсь, что Вы получили правильный отчёт в своем письме.

Давайте теперь создадим периодическую задачу. Откройте quick_publisher/celery.py и зарегистрируйте задания:

До сих пор мы создавали расписание, которое запускало задачу publisher.tasks.send_view_count_report каждую минуту, как показано в нотации crontab() . Вы также можете указать различные расписания Celery Crontab.

Откройте другую консоль, активируйте соответствующее окружение и запустите службу Celery Beat.

Работа службы Beat заключается в том, чтобы задавать задачи в Celery в соответствии с расписанием. Учтите, что расписание выполняет задачу send_view_count_report каждую минуту в соответствии с настройкой. Это удобно для тестирования, но не рекомендуется для реального веб-приложения.

Сделать задачи более надежными

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

  • Сделать задачи идемпотентными. Идемпотентная задача - это задача, которая, не изменяет состояние системы, если она остановлена на полпути. Задача либо полностью вносит изменения в систему, либо нет.
  • Повторение задачи. Если задача падает, рекомендуется попробовать выполнять ее снова и снова, пока она не будет выполнена успешно. Вы можете сделать это c помощью Celery Retry. Еще одна интересная вещь, на которую стоит обратить внимание, - это алгоритм экспоненциального отказа. Это может пригодиться, когда вы думаете об уменьшении ненужной нагрузки на сервер, возникающей из за повторных задач.

Заключение

Надеюсь, что это была интересная статья для вас и хорошее введение в использование Celery с Django.

Читайте также: