Первое, что нужно сделать, запуская проект на Django / Хабр
Приветствую сообщество, встала передо мной задача написать социальную сеть. А коль скоро язык программирования, которым я более-менее владею — это Python, я выбрал фреймворк Django для реализации проекта. Чтобы не тратить время на написание HTML шаблонов и CSS стилей, эти файлы я беру в интернете с пометкой Free. В основном это шаблоны от Colorlib.Поехали.
Сразу оговорюсь, что использую PyCharm, поэтому могу не знать все команды из файла manage.py.
После создания проекта в среде, как и в любом Django проекте, первое, что необходимо сделать — внести изменения в файле settings.py а именно:
- Меняем две переменные на
LANGUAGE_CODE = 'ru-ru' TIME_ZONE = 'Ваш часовой пояс/Ваш город' #Например: Europe/Moscow
- Добавить папку для статических и медиа файлов
# Static files STATIC_URL = '/static/' STATIC_ROOT = os.path.join(BASE_DIR, 'static') # Media files MEDIA_URL = '/media/' MEDIA_ROOT = os.path.join(BASE_DIR, 'media')
Далее создаём своё приложение командой
python manage.py startapp my_app
Насколько мне известно, хорошим тоном написания приложений на Django является разбиение проекта на отдельные приложения, и уже в них мы описываем функционал, который нам нужен. Такой подход обеспечивает лёгкий перенос приложений из одного проекта в другой, что очень удобно. Поехали дальше.
Как только приложение создано, нам нужно его зарегистрировать для того, чтобы начать его использовать. Добавим приложение в список используемых.
INSTALLED_APPS = [
'django.contrib.admin',
...
'django.contrib.staticfiles',
'my_app',#наше приложение
]
Далее необходимо определить url адрес для нашего приложения, что тоже является хорошим тоном разработки. В папке приложения (не путать с папкой проекта) нужно предварительно создать файл urls.py. А затем в папке проекта в файле urls.py импортируем функцию include и прописываем адрес. Об этом также написано в комментариях в самом файле.
from django.contrib import admin
from django.urls import path, include
urlpatterns = [
path('admin/', admin.site.urls),
path('', include('account.urls'))
]
Если на этом этапе мы запустим сервер командой
python manage.py runserver
в командной строке (в PyCharm кнопка «Запуск» или «Debug»), то получим ошибку, ведь в папке приложения файл urls.py (далее — account/urls.py) пустой.
Заполним его следующим кодом.
from django.urls import path
from . import views
urlpatterns = [
path('', views.index, name='login'),# при обращении к адресу ''(главная страница), будем использовать представление (термин Django) log
]
Теперь выйдет ошибка, потому что account/views.py пустой. Исправим.
from django.shortcuts import render #импорт функции # Create your views here. def index(request):#создаем свою функцию context = {}#с помощью словаря можем передать модель и форму в шаблон HTML return render(request, 'my_app/index.html', context)#собственно вызываем шаблон HTML
Почти готово. Что уже сделано:
- Создано приложение в проекте.
- Внесены изменения в настройках.
- Прописан адрес в главном urls.py проекта.
- В приложении создан файл urls.py и в нем прописано представление (views).
- В представлении (views) создана функция обработки url адреса и HTML шаблона.
Пора создать шаблон.
При создании проекта у нас автоматически создаётся папка ‘templates’, в ней нужно создать папку my_app, внутри my_app создать файл index.html. Для проверки в теге body можно записать:
<!DOCTYPE html>
<html lang="ru">
<head>
<meta charset="UTF-8">
<title>Заголовок</title>
</head>
<body>
<h3>Сайт работает.</h3>
</body>
</html>
и можно запускать сервер.
В итоге мы должны увидеть вот это (изображение):
Если на сайте используются какие-либо CSS стили или JavaScript файлы, а это 10 из 10 случаев, то нужно их подгрузить перед строкой DOCTYPE командой
{%load staticfiles%}
При этом в папке приложения создать папку «static», внутри держать CSS, JS и тд. А в HTML шаблоне в теге link параметре href указать абсолютный путь к файлу, например:
<link href="{% static 'css/style.css' %}" rel="stylesheet">
Итого, файл будет выглядеть вот так:
{%load staticfiles%}
<!DOCTYPE html>
<html lang="ru">
<head>
<meta charset="UTF-8">
<title>Заголовок</title>
<link href="{% static 'css/style.css' %}" rel="stylesheet">
</head>
<body>
<h3>Сайт работает.</h3>
</body>
</html>
В общем-то нам этом введение и заканчивается. Дальше все действия будут похожи, только суть будет разной. Будут разные формы (тег form в HTML) в файле forms.py приложения (нужно предварительно создать этот файл), будет разная логика приложений, описанная в views.py, ну и модели в базе данных, описанные в models.py. Но сам алгоритм действий тот же самый
- Создаём адрес.
- Создаём представление (логику).
- Создаём HTML шаблон.
- Связываем всё вместе.
+ — пара промежуточных действий в виде форм и моделей.
В блоге Metanit (ссылка внизу) хорошо описана суть Модель — Шаблон — Представление, копипастить не собираюсь, там же есть теория и про формы, и про модели.
В «Руководство Django Girls» (ссылка внизу) можно узнать подробней о расширении шаблонов HTML (крайне полезная фишка Django), о создании учётной записи администратора, о добавлении данных в созданные модели.
А я на этом заканчиваю. В следующей части будет код создания формы регистрации на сайте, а чтобы не мусорить на Хабре, дам ссылку на гитхаб. Успехов в главном, товарищи.
Ссылки на полезные ресурсы:
Блог про Django — Metanit
Руководство Django Girls
Django в примерах
10 основных ошибок, совершаемых Django-разработчиками / Блог компании Mail.ru Group / Хабр
В этом руководстве мы рассмотрим основные ошибки Django-разработчиков и узнаем, как их избежать. Статья может быть полезна даже опытным разработчикам, потому что и они совершают такие ошибки, как поддержка неподъёмно больших настроек или конфликтов имён в статических ресурсах.
Django — бесплатный сетевой open source Python-фреймворк, помогающий решать распространённые в разработке проблемы. Он позволяет создавать гибкие, хорошо структурированные приложения. В Django уже из коробки есть много современных возможностей. Например, для меня такие фичи, как Admin, инструмент Object Relational Mapping (ORM), Routing и Templating, делают Django первым кандидатом при выборе инструментария для разработки. Создание приложения требует много сил, и, наслаждаясь своим делом, как и любой разработчик, я хочу тратить как можно меньше времени на рутинные задачи. Django сильно в этом помогает, не заставляя жертвовать гибкостью приложения.
Киллер-фича Django — мощный конфигурируемый админский интерфейс, который автоматически (автомагически?) генерируется на основе схемы вашей модели и моделей админки. Чувствуешь себя прямо-таки волшебником. С помощью интерфейса Admin пользователь может конфигурировать много вещей, в их числе — список управления доступом (access control list, ACL), разрешения и действия на уровне строк (row-level), фильтры, порядки сортировки (orders), виджеты, формы, дополнительные URL-хелперы и многое другое. Я считаю, что админка нужна каждому приложению. Это лишь вопрос времени, когда такая панель понадобится вашему основному приложению. В Django она создаётся быстро и удобно.
Также в Django есть мощная ORM, из коробки работающая со всеми главными базами данных. Она «ленива»: в отличие от других ORM, обращается к БД только по мере необходимости. В ней есть поддержка основных SQL-инструкций (и функций), которые вы можете использовать из своего исходного Python-кода наряду со всеми остальными возможностями языка.
Фреймворк имеет и много других важных возможностей вроде URL-роутера, который парсит входящие запросы и генерирует новые URL на основе схемы роутинга. В целом Django приятен в работе, и, когда вам понадобится помощь, просто почитайте документацию.
Ошибка № 1. Использование для проектных зависимостей глобального окружения Python
Не используйте глобальное окружение Python для зависимостей вашего проекта, потому что это может привести к возникновению конфликтов зависимостей. Python не умеет работать с несколькими версиями пакетов одновременно. Это станет проблемой, если разным проектам нужны разные, несовместимые версии одного пакета.
Обычно такую ошибку допускают новички в Python- и Django-разработке, не знающие об особенностях изоляции окружения Python.
Есть много способов изолировать окружение, наиболее часто встречаются такие:
- virtualenv: пакет Python, генерирующий папку с окружением. Содержит скрипт для (де)активации окружения и управления установленными в нём пакетами. Это мой любимый и самый простой метод. Обычно я создаю окружение поближе к папке проекта.
- virtualenvwrapper: пакет Python, глобально устанавливающий набор инструментов для создания/удаления/активации и т. д. виртуальных окружений и предоставляющий доступ к этому набору. Все окружения хранятся в одной папке (её можно переписать с помощью переменной WORKON_HOME). Я не вижу преимуществ в использовании
virtualenvwrapper
вместоvirtualenv
. - Виртуальные машины: нет лучшей изоляции, чем целая виртуальная машина, выделенная под ваше приложение. Есть масса доступных инструментов, например VirtualBox (бесплатный), VMware, Parallels и Proxmox (мой фаворит, есть бесплатная версия). В сочетании с инструментом автоматизации виртуальных машин вроде Vagrant это может оказаться очень мощным решением.
- Контейнеры: в последние годы я почти в каждом проекте использую Docker, особенно в новых проектах, начинаемых с нуля. Docker — невероятный инструмент с множеством возможностей. Для его автоматизации доступна куча сторонних инструментов. В Docker есть кеширование уровней (layer caching), позволяющее крайне быстро пересоздавать контейнеры. В них я использую глобальное окружение Python, потому что каждый контейнер имеет собственную файловую систему и проекты изолируются на высоком уровне. Docker позволяет новым членам команды быстрее начинать работу над проектом, особенно если у них есть опыт работы с этой технологией.
Ошибка № 2. Отсутствие привязки зависимостей в файле requirements.txt
Каждый новый проект Python должен начинаться с файла requirements.txt и нового изолированного окружения. Обычно вы с помощью pip/easy_install
устанавливаете все пакеты, не забывая о requirements.txt
. Обычно проще (возможно, правильнее) развёртывать проекты на серверах или на машинах членов команды.
Также важно в файле requirements.txt выполнять привязку (pin) конкретных версий ваших зависимостей. Обычно разные версии пакета предоставляют разные модули, функции и параметры функций. Даже в младших версиях изменения зависимостей могут оказаться такими, что это сломает ваш пакет. Это очень серьёзная проблема, если у вас живой проект и вы планируете регулярно его развёртывать, так как без системы управления версиями ваша сборочная система всегда будет устанавливать последнюю доступную версию пакета.
В production всегда выполняйте привязку пакетов! Я для этого использую очень хороший инструмент pip-tools. Он предоставляет набор команд, помогающих управлять зависимостями. Инструмент автоматически генерирует requirements.txt
, в котором привязаны не просто ваши зависимости, а вообще всё дерево, т. е. и зависимости ваших зависимостей.
Иногда нужно обновить какие-то пакеты в списке зависимостей (например, только фреймворк или утилиту). Если вы прибегаете к pip freeze, то не знаете, какие зависимости используются какими пакетами, и поэтому не можете их обновить. Инструмент pip-tools автоматически привязывает пакеты в соответствии с привязанными вами зависимостями, и поэтому он автоматически решает, какие пакеты нужно обновить. А благодаря используемым комментариям в requirements.txt
вы всегда знаете, какой пакет пришёл из какой зависимости.
Если быть ещё более осторожным, то можно делать бекап исходных файлов ваших зависимостей. Храните копию в своей файловой системе, Git-папке, S3-папке, FTP, SFTP — где угодно, лишь бы под рукой. Бывают ситуации, когда исключение из списка относительно небольшого пакета ломает большое количество пакетов в npm. Pip позволяет скачивать все необходимые зависимости в виде исходных файлов. Почитайте об этом подробнее, выполнив команду pip help download
.
Ошибка № 3. Использование старомодных Python-функций вместо представлений-классов (Class-based Views)
Иногда целесообразно использовать в файле приложения views.py
маленькие Python-функции, особенно для тестовых или утилитарных представлений. Но обычно в приложениях нужно использовать представления на основе классов (CBV).
CBV — это представления общего назначения, предоставляющие абстрактные классы, реализующие распространённые задачи веб-разработки. CBV созданы профессионалами и покрывают большинство востребованных моделей поведения. У них есть прекрасно структурированный API, и CBV подарят вам возможность наслаждаться всеми преимуществами ООП. Ваш код будет чище и читабельнее. Забудьте о трудностях использования стандартных функций представления (view functions) Django для создания списков, CRUD-операций, обработки форм и т. д. Можно просто расширять подходящий CBV под ваше представление и переопределять (override) функции или свойства класса, конфигурирующие поведение представления (обычно функция возвращает свойство, и вы можете добавить в неё любую логику, которая способна превратить ваш код в спагетти, если вместо CBV вы прибегнете к функциям представления).
Например, можно использовать в проекте разные миксины, которые переопределяют основные модели поведения CBV: создание контекстов представлений, проверка авторизации на уровне строк (on the row level), автосоздание путей шаблонов на основе структур приложения, интегрирование умного кеширования и многое другое.
Я создал пакет Django Template Names, который стандартизирует имена шаблонов для ваших представлений на основе имени приложения и имени класса представления. Я пользуюсь им каждый день и экономлю кучу времени при выборе имён. Просто вставьте миксин в свой CBV — class Detail(TemplateNames, DetailView):
— и он начнёт работать! Конечно, можете переопределить мои функции и добавить мобильные адаптивные шаблоны, другие шаблоны для user-agent’ов или что-нибудь ещё.
Ошибка № 4. Написание «толстых» (fat) представлений и «тонких» (skinny) моделей
Если у вас логика приложения перенесена из модели в представления, это означает, что в представлениях находится код, принадлежащий модели. То есть представления становятся «толстыми», а модель — «тонкой».
А нужно писать «толстые» модели и «тонкие» представления.
Разбейте логику по маленьким методам в модели. Это позволит использовать их многократно и из многочисленных источников (админский пользовательский интерфейс, пользовательский интерфейс фронтенда, конечные точки API, многочисленные представления). Это займёт всего несколько строк кода, и вам не придётся копипастить кучу строк. Когда в следующий раз будете писать функциональность отправки письма пользователю, расширьте модель с помощью email-функции, а не пишите логику в контроллере.
Это сделает ваш код более удобным для модульного тестирования, потому что вы сможете протестировать логику электронной почты в одном месте, а не делать это в каждом контроллере. Подробнее об этой проблеме почитайте в Django Best Practices. Решение простое: пишите «толстые» модели и «тонкие» представления. Начните это делать уже в следующем проекте или рефакторьте текущий.
Ошибка № 5. Огромный, неповоротливый файл настроек
Даже в новом файле настроек Django-проекта этих настроек содержится множество. А в реальных проектах файл разрастается до 700+ строк, которые трудно сопровождать, особенно когда окружениям разработки, продакшена и стейджинга нужны разные конфигурации.
Вы можете вручную разделить конфигурационный файл и создать отдельные загрузчики, но я хочу порекомендовать отличный, хорошо протестированный Python-пакет Django Split Settings, соавтором которого я являюсь.
Пакет предоставляет две функции — optional
и include
, которые поддерживают подстановки (wildcards) для путей и импортируют ваши конфигурационные файлы в тот же контекст. Благодаря этому можно просто создавать конфигурации с помощью объявления конфигурационных записей в ранее загруженных файлах. Пакет никак не влияет на производительность Django и может применяться в любых проектах.
Вот пример минимальной конфигурации:
from split_settings.tools import optional, include
include(
'components/base.py',
'components/database.py',
'components/*.py',
# the project different envs settings
optional('envs/devel/*.py'),
optional('envs/production/*.py'),
optional('envs/staging/*.py'),
# for any local settings
optional(‘local_settings.py'),
)
Ошибка № 6. Приложение всё-в-одном, плохая структура приложения и некорректное размещение ресурсов
Любой Django-проект состоит из нескольких приложений. В терминологии Django приложение — это Python-проект, содержащий как минимум файлы __init__.py
и models.py
. В последних версиях Django models.py
больше не нужен, достаточно только __init__.py
.
Django-приложения могут содержать Python-модули, характерные для Django модули (представления, URL’ы, модели, админскую панель, формы, метки шаблонов и т. д.), статичные файлы, шаблоны, миграции базы данных, команды управления, модульные тесты и пр. Нужно разбивать своё монолитное приложение на маленькие многократно используемые приложения с простой логикой.
У вас должна быть возможность полностью описать назначение приложения одним-двумя короткими предложениями. Например: «Позволяет пользователю зарегистрировать и активировать по почте свой аккаунт».
Рекомендуется назвать папку проекта project и положить приложения в project/apps/
. Затем положить все зависимости приложений в собственные подпапки.
Примеры:
- Статичные файлы:
project/apps/appname/static/appname/
- Метки шаблона:
project/apps/appname/templatetags/appname.py
- Файлы шаблона:
project/apps/appname/templates/appname/
Всегда добавляйте имена приложений в виде префиксов в названия подпапок, потому что все статические папки объединяются в одну. И если два или более приложений имеют файл js/core.js
, то последнее приложение в settings.INSTALLED_APPLICATIONS
переопределит все предыдущие. Однажды я столкнулся с таким багом в своём проекте и потратил около шести часов на отладку, пока не сообразил, что другой разработчик переопределил мой static/admin/js/core.js
, потому члены команды реализовали кастомную админскую SPA-панель и дали своим файлам такие же имена.
Вот пример структуры для портального приложения, содержащего много ресурсов и Python-модулей.
root@c5b96c395cfb:/test# tree project/apps/portal/
project/apps/portal/
├── __init__.py
├── admin.py
├── apps.py
├── management
│ ├── __init__.py
│ └── commands
│ ├── __init__.py
│ └── update_portal_feeds.py
├── migrations
│ └── __init__.py
├── models.py
├── static
│ └── portal
│ ├── css
│ ├── img
│ └── js
├── templates
│ └── portal
│ └── index.html
├── templatetags
│ ├── __init__.py
│ └── portal.py
├── tests.py
├── urls.py
└── views.py
11 directories, 14 files
Благодаря такой структуре вы можете в любой момент экспортировать приложение в другой Python-пакет и снова его использовать. Можете даже опубликовать его в PyPi в качестве open source пакета или переместить в другую папку. У вас получится примерно такая структура проекта:
root@c5b96c395cfb:/test# tree -L 3
.
├── deploy
│ ├── chef
│ └── docker
│ ├── devel
│ └── production
├── docs
├── logs
├── manage.py
├── media
├── project
│ ├── __init__.py
│ ├── apps
│ │ ├── auth
│ │ ├── blog
│ │ ├── faq
│ │ ├── pages
│ │ ├── portal
│ │ └── users
│ ├── conf
│ ├── settings.py
│ ├── static
│ ├── templates
│ ├── urls.py
│ └── wsgi.py
└── static
└── admin
├── css
├── fonts
├── img
└── js
25 directories, 5 files
Конечно, реальный проект будет сложнее, но такая структура упрощает и делает более прозрачными многие аспекты.
Ошибка № 7. STATICFILES_DIRS и STATIC_ROOT смущают новичков в Django-разработке
Статичные файлы — это ресурсы (assets), которые не меняются по мере использования приложения. Например, JavaScript, CSS, изображения, шрифты и т. д. В Django они «накапливаются» в публичной директории в ходе развёртывания.
В режиме разработки — python manage.py runserver
— Django ищет статичные файлы с помощью настройки STATICFILES_FINDERS. По умолчанию он пытается найти запрошенный файл в папках, перечисленных в STATICFILES_DIRS. Если не находит, то ищет с помощью django.contrib.staticfiles.finders.AppDirectoriesFinder
, которая проверяет папку static
каждого установленного в проекте приложения. Такая схема позволяет писать многократно используемые приложения, поставляемые со своими собственными статичными файлами.
В production вы раздаёте статичные данные посредством отдельного веб-сервера, например nginx. Он ничего не знает о структуре приложений проекта Django или о том, по каким папкам распределены ваши статичные файлы. К счастью, Django предоставляет нам команду управления сбором статичных данных (collect static management command) — python manage.py collectstatic
, которая проходит по STATICFILES_FINDERS
и копирует все статичные файлы из папок static
приложений, а также из папок, перечисленных в STATICFILES_DIRS
, в заданную вами в STATIC_ROOT директорию. Это позволяет разрешать (resolution) ресурсы в виде статичных данных с помощью той же логики, что и у Django-сервера в режиме разработки, и собирать в одном месте для веб-сервера все статичные файлы.
Не забудьте выполнить collectstatic
в вашем production-окружении!
Ошибка № 8. Использование в production STATICFILES_STORAGE по умолчанию и загрузчиков Django-шаблонов
Давайте поговорим об управлении ресурсами (asset) production-окружения. Мы можем обеспечить наилучший UX, если воспользуемся политикой «у ресурсов не истекает срок действия» (assets never expire) (подробнее о ней можно почитать здесь). Это означает, что все наши статичные файлы должны быть закешированы браузерами на недели, месяцы или даже годы. Иными словами, пользователи должны лишь единожды скачивать ресурсы!
Классная идея, и её можно реализовать всего в несколько строк в nginx-конфигурации для нашей папки со статичными файлами. Но что насчёт проверки актуальности кеша? Если пользователь лишь один раз скачивает наш ресурс, то что делать в том случае, если вы обновите логотип, шрифты, JavaScript или цвет текста в меню? Для решения этой задачи вам нужно при каждом развёртывании генерировать уникальные URL’ы и имена для каждого статичного файла!
Для этого можно использовать ManifestStaticFilesStorage в качестве STATICFILES_STORAGE
(будьте осторожны, хеширование включается только в режиме DEBUG=false
) и выполнить команду collectstatic
. Это приведёт к снижению количества запросов ресурсов у вашего production-сайта и сделает его отрисовку гораздо быстрее.
Клёвая фича Django — закешированный загрузчик шаблона. Он не перезагружается и парсит файлы шаблона при каждой его отрисовке. Парсинг шаблона — очень дорогая операция, она требует много вычислительных ресурсов. По умолчанию Django-шаблоны парсятся при каждом запросе, а это плохо, особенно в production, где за короткий промежуток времени могут обрабатываться тысячи запросов.
В разделе конфигурации cached.Loader можно найти хороший пример и подробности решения проблемы. Не используйте загрузчик в режиме разработки, потому что он не перезагружает отпарсенные шаблоны из файловой системы. Вам понадобится перезапускать свой проект, используя python manage.py startapp
, при каждом изменении шаблона. При разработке это может раздражать, зато идеально для production-окружения.
Ошибка № 9. Чистый Python для утилит или скриптов
У Django есть отличная фича — команды управления. Используйте их вместо изобретения велосипеда в виде написания скриптов на чистом Python для утилит вашего проекта.
Также обратите внимание на пакет Django Extensions, представляющий собой коллекцию кастомных расширений для Django. Возможно, кто-то уже реализовал ваши команды! Существует много распространённых целевых команд.
Ошибка № 10. Велосипедостроение
Для Django и Python есть тысячи готовых решений. Обратитесь к поисковикам, прежде чем писать что-то, что вовсе не уникально. Вероятно, уже есть подходящее решение.
Не надо усложнять. Сначала — гуглим! Установите найденный качественный пакет, сконфигурируйте, расширьте и интегрируйте в свой проект. И если есть возможность, внесите свой вклад в open source.
Вот вам для начала список моих собственных пакетов для Django:
- Django Macros URL: с помощью макросов облегчает написание (и чтение) URL-паттернов в Django-приложениях.
- Django Templates Names: маленький миксин, помогает легко стандартизировать имена ваших CBV-шаблонов.
- Django Split Settings: позволяет распределить Django-настройки по нескольким файлам и директориям. Легко переопределяет и модифицирует настройки. Использует подстановки (wildcards) в путях файлов и помечает файлы настроек как опциональные.
Don’t repeat yourself (DRY)!
Я сторонник DRY-концепции, поэтому создал Django skeleton — удобный инструмент с рядом приятных функций уже из коробки:
- Docker-образы для разработки/production, управляемые docker-compose, что позволяет легко оркестрировать списком контейнеров.
- Простой Fabric-скрипт для развёртывания в production.
- Конфигурация для пакета Django Split Settings с настройками базы и локальных источников.
- Интегрированный в проект Webpack — при выполнении команды
collectstatic
Django соберёт только папку dist. - Сконфигурированы все основные Django-настройки и фичи вроде кешируемых в production Django-шаблонов, хешированных статичных файлов, интегрированного тулбара для отладки, журналирования и т. д.
Это готовый к использованию Django-скелет для вашего следующего проекта, создаваемого с нуля. Надеюсь, он сэкономит вам кучу времени. Webpack имеет минимальную базовую конфигурацию, но также в него с помощью SASS установлены заранее сконфигурированные для обработки файлы .scss.
Плюсы и минусы Django
Вы разработчик? Тогда очевидно, что вам нужен лучший язык программирования. Но определение лучшего языка и инструментов – непростая задача. Слышали ли вы о Django? Или, по крайней мере, знакомы ли вы с его минусами и плюсами? Используя данный инструмент, кажется, что все становится на свои места очень быстро и эффективно.
Почему Django?
Когда у вас возникает определенная мысль, трансформировать ее на языке программирования и предать ей реальную форму при помощи Django займет всего несколько минут. То, что Django находится в свободном доступе, дает возможность заметно упростить процесс веб разработки, так как разработчик может сфокусироваться на процессе дизайна и разработке функционала приложения. Таким образом, Django – это идеальный инструмент для стартапов, когда веб дизайн должен отображать концепцию и цели компании.
Django в центре внимания
Django появился в 2005 году, и постепенно стал одним из лучших фреймворков, который помогал и помогает тысячам разработчиков выполнять ту или иную работу в течение нескольких минут. Изначально Django был фреймворком для языка Python, с отличным функционалом, Django заметно упростил ряд сложностей в разработке веб приложений, придав данной работе более упрощенный подход
Python и его популярность
Хорошо известно, что Python является одним из самых используемых языков программирования благодаря простоте в изучении, дизайну и гибкости, что делает его практически совершенным языком программирования. Существует ряд причин, по которым его можно называть такими громкими словами.
- Простота в изучении
- Чистота и читаемость
- Разносторонность
- Быстрота написания
- Цельный дизайн
Однако, Python работает на собственной философии, называемой «Дзен Python». Эта философия дает ему уникальную форму, не имеющую аналогов в других языках программирования. Опираясь на эти принципы, разработчики могут создавать код высшего сорта.
Плюсы Django
Я уже достаточно расхвалил Python и его преимущество, так что давайте сфокусируемся на преимуществах Django, который является не только быстрым решением в веб разработке, включающим все необходимое для качественного кода и прозрачного написания, но также и отличной платформой для работы с клиентурой того или иного бизнеса, а так же разработчиков.
- Быстрота: Django был разработан, чтобы помочь разработчикам создать приложение настолько быстро, на сколько это возможно. Это включает в себя формирование идеи, разработку и выпуск проекта, где Django экономит время и ресурсы на каждом из этих этапов. Таким образом, его можно назвать идеальным решением для разработчиков, для которых вопрос дедлайна стоит в приоритете.
- Полная комплектация: Django работает с десятками дополнительных функций, которые заметно помогают с аутентификацией пользователя, картами сайта, администрированием содержимого, RSS и многим другим. Данные аспекты помогают осуществить каждый этап веб разработки.
- Безопасность: Работая в Django, вы получаете защиту от ошибок, связанных с безопасностью и ставящих под угрозу проект. Я имею ввиду такие распространенные ошибки, как инъекции SQL, кросс-сайт подлоги, clickjacking и кросс-сайтовый скриптинг. Для эффективного использования логинов и паролей, система пользовательской аутентификации является ключом.
- Масштабируемость: фреймворк Django наилучшим образом подходит для работы с самыми высокими трафиками. Следовательно, логично, что великое множество загруженных сайтов используют Django для удовлетворения требований, связанных с трафиком.
- Разносторонность: менеджмент контента, научные вычислительные платформы, даже крупные организации – со всем этим можно эффективно справляться при помощи Django.
PHP против Python
PHP можно назвать самым сильным конкурентом Python, оба эти языка очень популярны. Однако у Django есть парочка роялей в кустах, которыми не может похвастаться PHP. Нередко эти преимущества являются решающими для разработчиков. Выбор между PHP и Python – не самая простая задача, надеюсь следующие сравнения помогут вам сделать объективный вывод:
- Лучший дизайн: PHP был разработан специально для веб разработки, но Django базируется на более надежном языке. Хороший код проще написать в Python, в сравнении с PHP.
- Python и долгосрочность: PHP очень хорош в краткосрочной перспективе. Однако, когда вы проходите начальную фазу, вам может понадобиться язык с более глубокими возможностями. Здесь Python выступает в роли явного фаворита.
- Лучший Веб Фреймворк: Рынок наполнен великим множеством замечательных фреймворков. Однако это не касается долгосрочной ценности. И Django в данном случае является явным победителем. Хотя и PHP может похвастаться со своими Laravel, Yii, Symfony.
- Фактор читаемости: PHP следует классическому подходу, но у Python более строгие правила идентификации. Отсюда выбирайте, что лучше.
- Простой синтаксис: написание кода в Python происходит намного проще и быстрее.
- Инструменты для лечения багов: пакеты Python содержат все необходимые инструменты для исправления неполадок.
- Управление пакетам: в Python это реализовано весьма эффективно: вы можете писать, читать и делиться пакетами таким образом, что другие разработчики могут использовать их в других приложениях.
- Говорим Python, подразумеваем «Общее Назначение»: В то время как PHP используется для веб разработки, Python может быть использован для различных целей, также стоит отметить, что вы можете работать как онлайн, так и оффлайн.
Минусы
Минусы всегда идут за руку с плюсами. Давайте рассмотрим, почему Django нельзя назвать безупречным:
- Использование шаблона маршрутизации с указанием URL
- Django слишком монолитный
- Все базируется на ORM Django
- Компоненты развертываются совместно
- Необходимо умение владеть всей системой для работы
Подведем итоги
Существует очень много плюсов и минусов Django, не упомянутых в данной статье, однако, когда рассматривается проект с дедлайном, использование Django для решения поставленной задачи – грамотное решение. Более того, для ускорения рабочего процесса, есть возможность установить пользовательскую кастомную конфигурацию. Ранее, когда разработка кода требовала большого количества времени, такая возможность позволила заметно упростить этот процесс. Стоимость разработки снизилась практически на 80%, а необходимость в аутсорсинге вообще отпала. Но погодите, делает ли это Django лучшим? Что-ж, в некоторых странах определенно попытаются передать Django на аутсорс. Кому? Скорее всего, низкоквалифицированным и дешевым разработчикам.
Плюсы и минусы Django / Хабр
Прим. перев.: Эта статья рассчитана в основном на тех кто только выбирает фреймворк для веб-разработки. Опытные разработчики на Django вряд ли узнают что-то новое.
Django описывают как «веб-фреймворк для перфекционистов с дедлайнами». Его создали, чтобы переходить от прототипов к готовым сервисам как можно быстрее.
Фреймворк поможет разработать CRUD приложение под ключ. С Django не придется изобретать велосипед. Он работает из коробки и позволит сосредоточиться на бизнес-логике и продуктах для обычных людей.
Плюсы Джанго
Принцип «Всё включено» («Batteries included»)
Фраза «всё включено» означает, что большинство инструментов для создания приложения — часть фреймворка, а не поставляются в виде отдельных библиотек.
Django содержит огромное количество функциональности для решения большинства задач веб-разработки. Вот некоторые из высокоуровневых возможностей Django, которые вам придётся искать отдельно, если вы предпочтёте микро-фреймворк:
- ORM
- Миграции базы данных
- Аутентификация пользователя
- Панель администратора
- Формы
Стандартизированная структура
Django как фреймворк задаёт структуру проекта. Она помогает разработчикам понимать, где и как добавлять новую функциональность.
Благодаря одинаковой для всех проектов структуре гораздо проще найти уже готовые решения или получить помощь от сообщества. Огромное количество увлеченных разработчиков поможет справиться с любой задачей гораздо быстрее.
Приложения Django
Приложения в Django позволяют разделить проект на несколько частей. Приложения устанавливаются путём добавления в settings.INSTALLED_APPS. Этот подход позволяет легко интегрировать готовые решения.
Сотни универсальных модулей и приложений очень сильно ускорят разработку. Взгляните на их список на сайте djangopackages.org.
Безопасный по умолчанию
Django безопасен из коробки и включает механизмы предотвращения распространенных атак вроде SQL-инъекций (XSS) и подделки межсайтовых запросов (CSRF). Подробнее об этом можно почитать в официальном руководстве по безопасности.
REST Framework для создания API
Django REST Framework, который часто сокращают до «DRF», является библиотекой для построения API. Он имеет модульную и настраиваемую архитектуру, которая хорошо работает для создания как простых, так и сложных API.
В DRF политики аутентификации и разрешений доступны из коробки. Он поставляется с базовыми классами для CRUD операций и встроенной утилитой для тестирования разрабатываемого API.
GraphQL фреймворк для создания API
Большие REST API часто требуют большого количества запросов для получения всех необходимых данных. GraphQL — это язык запросов, который позволяет обмениваться связанными данными гораздо проще. Подробнее почитать про основные концепции GraphQL можно в официальной документации.
Graphene-Django позволит легко добавить соответствующую функциональность в ваш проект. Модели, формы, аутентификация, политики разрешений и другие функциональные возможности Django можно использовать для создания GraphQL API. Библиотека так же поставляется с утилитой для тестирования результата.
Недостатки Джанго
Django ORM
Django ORM сегодня значительно уступает последней SQLAlchemy.
Django ORM основан на шаблоне Active Record, который хуже, чем шаблон Unit of Work, используемый в SQLAlchemy. На практике это выражается в том, что в Django модели могут «сохранять» себя по желанию, а транзакции отключены по умолчанию. Подробнее об этом можно почитать в статье «Вещи, которые мне не нравятся в Django».
Django развивается медленно
Django является большим и монолитным фреймворком. Это позволяет сообществу разрабатывать сотни универсальных модулей и приложений, но снижает скорость разработки самого Django. Кроме того, фреймворк должен поддерживать обратную совместимость, поэтому он развивается относительно медленно.
В итоге: должен ли я выбрать Django?
Хотя Django ORM не так гибок, как SQLAlchemy, а большая экосистема многократно используемых модулей и приложений замедляет развитие инфраструктуры, очевидно, Django должен быть первым кандидатом на роль фреймворка для питониста.
Альтернативные легкие фреймворки типа Flask, хотя и позволяют быть свободнее Django в экосистеме и конфигурации, могут потребовать лишнего времени на поиск/создание дополнительных библиотек и функциональных возможностей в долгосрочной перспективе.
Стабильность Django и сообщество вокруг него выросли до невообразимых размеров с момента первого релиза. Официальная документация и учебные пособия по фреймворку являются одними из лучших в своём роде. А с каждой новой версией Django продолжает обрастать возможностями.
Руководство по Django
Последнее обновление: 07.03.2018
Содержание руководства по созданию веб-приложений на языке Python с помощью фреймворка Django.
Глава 1. Введение в Django
Что такое Django
Установка и настройка Django
Создание первого проекта
Создание первого приложения
Глава 2. Представления и маршрутизация
Обработка запроса
Определение маршрутов и функции path и re_path
Параметры представлений
Параметры строки запроса
Переадресация и отправка статусных кодов
Глава 3. Шаблоны
Создание и использование шаблонов
Передача данных в шаблоны
Статические файлы
TemplateView
Конфигурация шаблонов
Расширение шаблонов
Встроенные теги
Глава 4. Формы Django
Определение форм
Типы полей формы
Настройка формы и ее полей
Валидация данных
Детальная настройка полей формы
Стилизация полей форм
Глава 5. Модели
Создание моделей и миграции базы данных
Типы полей моделей
CRUD. Операции с моделями
Создание и получение объектов модели
Редактирование и удаление объектов модели
Отношение один ко многим (One to Many)
Отношение многие ко многим (Many to Many)
Отношение один к одному (One to one)
Самый полный видеокурс по Django от установки до проекта
Язык Python можно также использовать для написания сайтов. Вот занимательный видеокурс по Django на примере создания интернет-магазина.
Вас интересует фреймворк Django? Тогда вы по адресу. Оставим библиотеки, модули и трюки позади. Разберем Django по косточкам 😉
Эта лекция является вступительной в видеокурс по Django, в ней будет рассматриваться установка необходимого софта для работы с Python и Django. Автор показывает: процесс установки Python, настройки всех переменных, установки Django через pip, а также установку IDE PyCharm и его тестовый запуск.
Чтобы начать разрабатывать свой первый проект, нужно хорошенько разобраться со структурой IDE. После структуры в ролике пойдет речь об очень важной теме: как фреймворк Django взаимодействует с пользователем, о стилях и переменных.
Данный урок будет посвящен созданию блоков функционала, разнесенного по разным файлам. Такой подход облегчит разработку и скорость работы проекта. Второй крупной темой видео будет работа с базой, инициализация и «общение» с таблицами.
В этой лекции автор расскажет о кастомизации админки и отображении записей. Попутно разъясняется синтаксис языка Python, процесс создания элементов страницы, изменения имени модели, а также проводится траблшутинг.
В этом ролике создается веб-станица на примере готового шаблона. Для понимания всего происходящего пригодятся знания основ верстки, а также сильно облегчит жизнь опыт работы с элементами Bootstrap.
На прошлых уроках была создана страница на Bootstrap, а теперь пришло время заняться логикой. Будет создана структура БД, и автор уделит значительное внимание связям между таблицами и моделями Django.
Данный урок научит создавать логику для просчета общей стоимости товара в заказе, исходя из количества, а также просчет, исходя из стоимости товаров при помощи метода save и сигнала post_save.
Автор выбирает шаблон для будущего магазина, подробно разбирает каждый из них на предмет плюсов и минусов и рассматривает основные элементы UI.
На прошлом уроке был выбран и разобран по кирпичикам шаблон, а на этом уроке будет рассматриваться наследование в шаблонах, подключение внешних HTML-файлов. Кроме того, вы научитесь использовать циклы, для получения данных из каждой записи в массиве.
https://www.youtube.com/watch?&v=PF1hh5ePcKI
Допиливание и переделка кода происходит на протяжении всего видеокурса, а в этом ролике происходит создание и добавление страницы товара. Автор показывает, как по id из url можно работать с товаром.
В этом ролике вы узнаете, как создать корзину при помощи jQuery и Ajax для интернет-магазина на Django. Поймете, как все динамические инструменты взаимодействуют с движком и между собой.
Этот урок продолжает видеокурс по Django framework, в котором будет происходить работа с Ajax по сохранению информации о товаре в БД. Будет создана модель для корзины и доработано взаимодействие фронтенда и бекенда.
Context processor – важная тема, поэтому сейчас вы научитесь создавать свой процессор для переменных, доступных со всех страниц. В лекции это показано на примере товаров в корзине.
Это последнее видео из серии про Ajax и jQuery, в котором вы узнаете, как происходит удаление товаров из корзины.
В этом видео автор показывает, как можно создать фронтенд формы для чекаута выбранного товара. Также будут рассмотрены формы Django и то, как в них можно динамически подгружать информацию.
На прошлом уроке был создан фронтенд, а здесь создается бекенд страницы чекаута для интернет-магазина. Вы научитесь пересохранять данные из модели «Товары» в корзине в модель «Товары» в заказе.
Этот видеокурс по Django посвящен запуску проекта на сервере в интернете. В качестве ОС была выбрана Ubuntu. Весь процесс подробно описан от регистрации до запуска.
Заключительная лекция курса и последняя часть по работе с удаленным сервером с рабочим проектом. Автор рассказывает, как запустить Django на сервере при помощи связки nginx + gunicorn.
А с какими трудностями столкнулись вы, работая с Django framework?
Создаем Todo приложение c помощью Django. Часть 1
И снова здравствуйте. В преддверии старта курса «Web-разработчик на Python» наш внештатный автор подготовил интересный материал, которым с радостью делимся с вами.
Джанго это мощный фреймворк для создания веб-приложений. Изначально Django был создан для того, чтобы быстро создавать, например, новостные сайты (или другие сайты, который нужно создавать максимально быстро). И после нативного PHP не покидает ощущение, что ты едешь на очень быстрой машине разработки. Чтобы посмотреть все его возможности для быстрой разработки, мы с вами попробуем создать простое Todo — приложение.
Начнем с формулировки краткого т.з. У нас будет небольшое веб-приложение с версткой на Bulma (да, я очень люблю Bulma. Возможно, когда-нибудь я сверну на Bootstrap или Picnic, но всему свое время). У нас (пока) нет авторизаций и пользователь может создавать, редактировать и удалять либо категорию дел, либо карточку todo, которая связана с какой-либо категорией, которую создал пользователь. Todo карточку или категорию можно удалить, поставив галочку на checkbox и нажав кнопку удалить.
Основные концепции Django
Немного поговорим о Django. Django реализует архитектурный паттерн MVT (Модель Представление Шаблон), которая немного отличается от знакомого большинству MVC (Модель Представление Контроллер) на котором работает Ruby on Rails и Laravel.
Модель (Model) Модель в Django описывает схему данных в БД. С Django ORM, вы можете самостоятельно описывать поля и любые другие типы данных, и совершать миграции для упрощения разработки.
Представление (View) В представлении в Django вы задаете основную логику и алгоритмы приложения, получаете различные данные из базы данных или манипулируете ими. Представление обычно базируется на функциях request\response. Response представляет из себя обычно HTTP redirect, HTTP error(404), MimeTypes или какой-либо шаблон.
Шаблон Шаблон в Django это простой HTML код со специальным шаблонным языком Django. DTL (Django Template Language) — это язык, с помощью которого вы можете динамически менять содержимое страницы (к примеру, изменять имя пользователя на странице, в зависимости от того, как зовут авторизовавшегося пользователя).
Настройки Файл настроек в Django, в котором находятся все настройки вашего веб-приложения. Он включает в себя секретный ключ, папки с шаблонами, middlewares (которые отвечают, например за то, чтобы ваши приватные альбомы не увидели другие пользователи), подключение к базе данных, и много всего остального.
Url Файл настройки роутинга — примерно то же самое, что и в Angular или Laravel. Это связывает представление с url запросами.
Страница Админа Так как Django изначально был спроектирован для быстрого прототипирования и развертывания новостных сайтов, админка включена в комплект по умолчанию.
Установка Python и Django
Творческое отступление
Автор этой статьи (то есть я) кроме написания статей занимается еще и обучением основам питона детей. По долгу службы я ставил Python и его пакеты на достаточно большое количество разнообразных машин. И кроме переустановок питона, один раз для установки пакета глобально сработал даже даунгрейд версии языка. Да, так тоже бывает.
Версии Python
До последнего времени активно поддерживались и развивались две основные ветки Python: 2.7 и 3.x. Я буду использовать версию 3.7.3 в данной статье, но на самом деле это не так важно. Если вы правда хотите знать разницу между ними, есть специальная вики. С другой стороны, сейчас уже нет никакого смысла использовать Python версии 2.7 — обновление языка остановилось на 2.7.17 (если я правильно понимаю документацию на официальном сайте). Это означает, что есть смысл переводить проекты написанные на Python 2.7.x на новую ветку, а вот новые писать на 2 версии совсем бессмысленно.
Инсталляция Python
Если вы работаете на Mac или Ubuntu — у вас уже скорее всего установлен Python, однако 2 версии. Python третьей версии придется скачивать отдельно, и вызывать его в командной строке вы сможете через python3. В любом случае, лучше всего скачать последний релиз здесь.
Создание своего виртуального окружения
На самом деле первое приложение на Django вы можете начать разрабатывать и не создавая свое виртуальное окружение, однако навык создания виртуального окружения может пригодится если вы, например, разрабатываете приложение с определенной версией библиотеки и не хотите устанавливать библиотеки глобально и замусоривать ваш system.
Так как же использовать virtual env?
1) Самый простой вариант. Вы можете скачать замечательный IDE от JET BRAINS PyCharm Community Edition отсюда. После установки PyCharm создайте новый проект, и Pycharm по умолчанию предложит вам создать Virtual Env, в котором будет возможность установить нужную версию Django (или по умолчанию последнюю, которая на момент написания данной статьи 3.0.2):
pip3 install django
2) Чуть более хардкорный вариант:
А что, если вы хотите запустить Django в virtual env, к примеру, в любимой папке?
Во, первых, создаем папку, в которой мы будет творить:
mkdir myfirstdjango && cd myfirstdjango
Дальше вводим следующие команды для активации venv, где django_env имя нашего виртуального окружения:
python3 -m venv django_env
source django_env/bin/activate
Далее наше виртуальное окружение активировалось. Можем поставить необходимые пакеты. В нашем случае это Django:
pip3 install django
Если вы захотите выключить виртуальное окружение, чтобы вернуться в ваш глобальный python (вернуться в контекст system), введите следующую команду:
deactivate
Хорошо, надеюсь с виртуальным окружением мы разобрались. Если возникли какие-то проблемы и дополнительные вопросы, полезные ссылочки можно найти здесь и здесь .
Создание самого проекта
Допустим вы выбрали какой-то из способов создания своего виртуального окружения (или даже делаете все глобально, что же, никто не запрещает вам это делать). Теперь проходим в папку проекта и начинаем его создание:
django-admin startproject todo #создаем корневую папку вашего проекта
cd todo #проходим в нее
python manage.py startapp todolist #как бы подприложение todolist
python3 manage.py runserver 8100 #поднимаем сервер на нашем любимом незанятом порте, 8000 по умолчанию
Так, после того как Django открыл стартовую страницу, необходимо проинсталлировать наше приложение todolist в основное приложение. Открываем
settings.py
и добавляем в уже имеющийся список приложений наш собственный todolist:INSTALLED_APPS = [
#предустановленные админки, аутентификации и остальное из коробки, не вижу смысла здесь перечислять
'todolist',
]
Следующим шагом будет связывание приложения с базой данных. Если базы данных — это не то, с чем вы хотите возиться, вам стоит воспользоваться решением по умолчанию — SQlite. Я же решил воспользоваться PostgreSQL — она популярна и классически связана с Django, кроме того, потом мы можем захотеть увеличить производительность приложения. Инструкций как устанавливать PostgreSQL на все операционные системы достаточно много. Я разрабатываю под MacOS и не без небольших танцев с бубном я поставил эту базу данных, скачав сам Postgres.app отсюда . Что касается интерфейсов для БД, то здесь я воспользовался Postico и пробной версии для разработки приложения нам вполне хватит (хотя в принципе можно обойтись и без неё, потому что все наше взаимодействие с базой данных будет построено через само веб-приложение и миграции). Кроме того, пришлось поставить psycopg2 в виртуальное окружение проекта (без этого драйвера с БД ваше приложение работать не будет).
Дальше нужно настроить работу статики. По-прежнему редактируем файл settings.py
, теперь в самом конце добавляем работу со статикой:
STATIC_URL = '/static/'
PROJECT_ROOT = os.path.dirname(os.path.abspath(__file__))
STATIC_ROOT = os.path.join(PROJECT_ROOT, 'static')
STATICFILES_STORAGE = 'whitenoise.django.GzipManifestStaticFilesStorage'
Для того, чтобы у вас заработала статика, проверьте что в списке INSTALLED_APPS находился пакет, отвечающий за статику:
django.contrib.staticfiles,
на тот случай, если произойдет ошибка.
И последнее в подготовительных работах, нам нужно ещё настроить базовую работу url в проекте:
from django.conf.urls import url
from django.contrib import admin
from todolist.views import todo
from todolist.views import category
from todolist.views import redirect_view
urlpatterns = [
url(r'$^', redirect_view ),
url(r'^admin/', admin.site.urls),
url(r'^todo/', todo, name="TodoList"),
url(r'^category/', category, name="Category"),
]
Я добавил редирект так как хочу, чтобы с дефолтной страницы localhost сразу переходил на подстраницу category(чтобы не дай бог пользователь не потерялся). Также у нас есть роутинг на две страницы: категорий и дел.
Итак, надеюсь ваше приложение не упало. Далее мы можем наконец-то переходить к созданию самого приложения:
Создание модели Todo и Категорий
Дальше приступим к созданию модели, которая будет базово взаимодействовать с нашей базой данных. Для создания модели открываем файл
models.py
в нашем todolist и начинаем творить. Начнем с того, что создадим таблицу категорий:from django.utils import timezone #мы будем получать дату создания todo
from django.db import models
class Category(models.Model): # Таблица категория которая наследует models.Model
name = models.CharField(max_length=100) #varchar.Нам потребуется только имя категории
class Meta:
verbose_name = ("Category") # человекочитаемое имя объекта
verbose_name_plural = ("Categories") #человекочитаемое множественное имя для Категорий
def __str__(self):
return self.name # __str__ применяется для отображения объекта в интерфейсе
Отлично! Да, здесь у нас будет только две колонки в таблице Категорий: id и name. Дальше создадим таблицу для наших дел. Думаю, из комментариев все понятно:
class TodoList(models.Model):
title = models.CharField(max_length=250)
content = models.TextField(blank=True) #текстовое поле
created = models.DateField(default=timezone.now().strftime("%Y-%m-%d")) # дата создания
due_date = models.DateField(default=timezone.now().strftime("%Y-%m-%d")) #до какой даты нужно было сделать дело
category = models.ForeignKey(Category, default="general",on_delete=models.PROTECT) # foreignkey с помощью которой мы будем осуществлять связь с таблицей Категорий
class Meta: #используем вспомогательный класс мета для сортировки наших дел
ordering = ["-created"] #сортировка дел по времени их создания
def __str__(self):
return self.title
После того, как ваша модель будет готова, необходимо создать миграции:
python3 manage.py makemigrations
И потом запускаете сами миграции:
python3 manage.py migrate
Создание view
Откроем файл
view.py
в todolist и отредактируем его. Для начала добавим необходимые импорты и редирект с главной на category:from django.shortcuts import render, redirect #для отображения и редиректа берем необходимые классы
from django.http import HttpResponse
from .models import TodoList, Category #не забываем наши модели
def redirect_view(request):
return redirect("/category") # редирект с главной на категории
Потом начинаем создание нашего дела. У экземпляра дела будут поля самого текста, даты, до которой должно быть закончено дело, категория дела, и объединенный контент:
def todo(request):
todos = TodoList.objects.all() #запрашиваем все объекты todo через менеджер объектов
categories = Category.objects.all() #так же получаем все Категории
После этого добавим функции добавления и удаления дел:
if request.method == "POST": #проверяем то что метод именно POST
if "Add" in request.POST: #проверяем метод добавления todo
title = request.POST["description"] #сам текст
date = str(request.POST["date"]) #дата, до которой должно быть закончено дело
category = request.POST["category_select"] #категория, которой может выбрать или создать пользователь.
content = title + " -- " + date + " " + category # полный склеенный контент
Todo = TodoList(title=title, content=content, due_date=date, category=Category.objects.get(name=category))
Todo.save() # сохранение нашего дела
return redirect("/todo") # перегрузка страницы (ну вот так у нас будет устроено очищение формы)
if "Delete" in request.POST: #если пользователь собирается удалить одно дело
checkedlist = request.POST.getlist('checkedbox') # берем список выделенные дел, которые мы собираемся удалить
for i in range(len(checkedlist)): #мне почему-то не нравится эта конструкция
todo = TodoList.objects.filter(id=int(checkedlist[i]))
todo.delete() #удаление дела
return render(request, "todo.html", {"todos": todos, "categories": categories})
С тудушками все. Дальше можем перейти к странице Категорий. Создаем функцию категорий, в которой у нас тоже будет функция добавления и удаления категории. Принципиально здесь ничего нового не будет, у нас так же здесь будет возможность добавления и удаления:
def category(request):
categories = Category.objects.all() #запрашиваем все объекты Категорий
if request.method == "POST": #проверяем что это метод POST
if "Add" in request.POST: #если собираемся добавить
name = request.POST["name"] #имя нашей категории
category = Category(name=name) #у нашей категории есть только имя
category.save() # сохранение нашей категории
return redirect("/category")
if "Delete" in request.POST: # проверяем есть ли удаление
check = request.POST.getlist('check') #немного изменил название массива в отличии от todo, что бы было меньше путаницы в коде
for i in range(len(check)):
try:
сateg = Category.objects.filter(id=int(check[i]))
сateg.delete() #удаление категории
except BaseException: # вне сомнения тут нужно нормально переписать обработку ошибок, но на первое время хватит и этого
return HttpResponse('<h2>Сначала удалите карточки с этими категориями)</h2>')
return render(request, "category.html", {"categories": categories})
На этом мы заканчиваем с файлом
view
и можем переходить к шаблонам:Работа с шаблонами
Как вы помните, чтобы не писать css лишний раз, я воспользовался
bulma.css
для упрощения верстки. Т.к. наши страницы категорий и todo буду очень схожи, я создал три файла:base.html
, который будет включать в себя все одинаковое, что у нас есть на страницах, а в category.html
, todo.html
будут располагаются отличия:Создаем base.html
и редактируем его:
<!DOCTYPE html>
<html lang="ru">
<head>
<meta charset="UTF-8">
<title> Приложение для дел</title>
{% load static %}
<link rel="shortcut icon" type="image/png" href="{% static 'favicon.png' %}"/>
<link rel="stylesheet" type="text/css" href="{% static 'bulma.min.css' %}">
<link rel="stylesheet" href="https://stackpath.bootstrapcdn.com/font-awesome/4.7.0/css/font-awesome.min.css">
</head>
<body>
<div django-app="TaskManager">
<nav class ="navbar is-success" role="navigation" aria-label="main navigation">
<div>
<div>
<a href="../category"> Категории</a>
<a href="../todo"> Список дел </a>
</div>
</div>
</nav>
<!-- в блок контент мы будем подгружать наши странички категорий и тудушек-->
{% block content %}
{% endblock %}
</div>
</body>
</html>
Дальше у нас пойдут страницы
todo.html
и category.html
:Тудушка:
{% extends 'base.html' %}
{% block content %}
<div>
<!-- на самом деле можно было обойтись и hero, но я обратился к inline-css -->
<div>
<h2> Список дел </h2>
<form action="" method="post">
{% csrf_token %}
<!-- csrf для базовой безопасности нашего приложения -->
<div>
<label for="description">Введите дело</label>
<div>
<input type="text" placeholder="Чем собираетесь заняться?"
name="description" required>
</div>
</div>
<div>
<div>
<label for="category">Категории</label>
<div>
<div>
<select name="category_select" required>
<!--поставишь такой required, и не надо пустые поляв бд валидизировать. Не повторять в продакшене-->
<option value="">Выберите категорию дела</option>
{% for category in categories %}
<option value="{{ category.name }}" name="{{ category.name }}">
{{ category.name }}</option>
{% endfor %}
</select>
</div>
</div>
</div>
<div>
<label for="dueDate">Выберите дату</label>
<input type="date" name="date" required>
</div>
</div>
<div>
<div>
<button name="Add" type="submit">
<span>
<i></i>
</span>
<span>Добавить задание</span>
</button>
<button name="Delete" formnovalidate="" type="submit">
<span>
<i></i>
</span>
<span>
Удалить дело
</span>
</button>
</div>
</div>
<div>
{% for todo in todos %}
<!-- шаблонный язык django- for loop -->
<div>
<label>
<input type="checkbox" name="checkedbox" value="{{ todo.id }}">
<span>{{ todo.title }}</span>
</label>
<span>{{ todo.category }}</span>
<strong><i></i>{{ todo.created }} -
{{ todo.due_date }}</strong>
</div>
{% endfor %}
</div>
</form>
</div>
</div>
{% endblock %}
И
category.html
. В ней у нас не особо много чего меняется, принципиально никак не отличается от todo.html
:{% extends 'base.html' %}
{% block content %}
<div>
<div>
<h2> Отредактируйте ваши категории </h2>
<form action="" method="post">
{% csrf_token %}
<!-- csrf для базовой безопасности нашего приложения -->
<div>
<label for="description"> Введите категории </label>
<div>
<input type="text" placeholder="Какого рода у вас дела?"
name="name" required>
</div>
<div>
<button name="Add" type="submit">
<span>
<i></i>
</span>
<span>Добавить категорию</span>
</button>
<button name="Delete" formnovalidate="" type="submit">
<span>
<i></i>
</span>
<span> Удалить категорию </span>
</button>
</div>
</div>
<!-- cписок наших категорий -->
<div>
{% for category in categories %}
<div>
<label>
<input type="checkbox" name="check" value="{{category.id}}">
<span>{{ category.name }}</span>
</label>
</div>
{% endfor %}
</div>
</form>
</div>
{% endblock %}
Всем спасибо! На этом все. Возможно, где-то не идеальна верстка, или есть другие предложения по улучшению приложения, всех жду в комментарии. По традиции, несколько полезных ссылок:
- Официальная документация Django, если вы хотите разрабатывать на новой 3 версии
- В русскоязычной интернете не так много хороший гайдов по поводу ООП, но этот мне кажется самым полезным
- Русскоязычная документация на PostgreSQL
dfunckt / django-rules: отличная авторизация Django, без базы данных
перейти к содержанию Зарегистрироваться- Почему именно GitHub?
Особенности →
- Обзор кода
- Управление проектами
- Интеграции
- Действия
- Пакеты
- Безопасность
- Управление командой
- Хостинг
- мобильный
- Истории клиентов →
- Безопасность →
- Команда
- Предприятие
- Проводить исследования
- Изучите GitHub →
Учитесь и вносите свой вклад
- Темы
- Коллекции
- В тренде
- Учебная лаборатория
- Руководства с открытым исходным кодом
Общайтесь с другими
- События
- Форум сообщества
- GitHub Education
— документация django-rules-light 0.1.3
Установить
Либо установите последнюю версию:
pip установить django-rules-light
Либо установите версию для разработки:
pip install -e git + https: //github.com/yourlabs/django-rules-light.git#egg=django-rules-light
Этого должно хватить для работы с реестром.
Промежуточное ПО
Для включения промежуточного программного обеспечения, обрабатывающего rules_light. Запрещено
исключение, добавить к настройкам .КЛАССЫ СРЕДНЕГО ОБЕСПЕЧЕНИЯ
:
MIDDLEWARE_CLASSES = ( # ... 'rules_light.middleware.Middleware', )
Дополнительные сведения см. В документации по промежуточному программному обеспечению.
Автообнаружение
Для включения автоматического обнаружения правил в различных установленных приложениях
в вашем проекте добавьте к urls.py
(как можно раньше):
импорт rules_light rules_light.autodiscover ()
Дополнительные сведения см. В документации по реестру.
Лесозаготовки
Чтобы включить ведение журнала, добавьте регистратор rules_light
, например:
LOGGING = { #... 'handlers': { # ... 'приставка':{ 'level': 'DEBUG', 'class': 'logging.StreamHandler', }, }, 'loggers': { 'rules_light': { 'обработчики': ['консоль'], 'распространять': Верно, 'level': 'DEBUG', } } }
Дополнительные сведения о ведении журнала см. В документации по журналированию.
Просмотр отладки
Добавить в настройки .INSTALLED_APPS
:
INSTALLED_APPS = ( 'rules_light', #.rules / ', включить (' rules_light.urls ')),
Дополнительные сведения о правилах отладки см. В документации по отладке.
Создание правил
Объявить правила
Правила объявления состоят из заполнения rules_light.registry
dict. это
dict использует «имена» правил как ключи, т.е. do_something
, г. some_app.some_model.create
и т. Д. И т. Д. Для значений можно использовать логические значения:
# Разрешить чтение для всех rules_light.registry ['your_app.your_model.read '] = Верно # Отключить удаление для всех rules_light.registry ['your_app.your_model.delete'] = Ложь
Дополнительно, используйте метод Python dict setdefault ()
в правилах по умолчанию. Для
пример:
# Разрешить всем, только если другой (специфичный для проекта) обратный вызов не был установлен rules_light.registry.setdefault ('your_app.your_model.read', Истина)
Он также может использовать обратные вызовы:
def your_custom_rule (пользователь, имя_правила, модель, * args, ** kwargs): если пользователь в модели.your_custom_stuff: return True # Разрешить пользователю! rules_light.registry ['app.model.read'] = ваше_пользовательское_правило
Дополнительные сведения см. В документации по реестру.
Правила смешивания, СУХАЯ безопасность
Обратные вызовы также могут использоваться для украшения друг друга, используя rules_light.make_decorator ()
преобразует простой обратный вызов правила в
обратный вызов правила, который также может использоваться как декоратор для другого обратного вызова.
Просто украсьте обратный вызов с помощью make_decorator ()
, чтобы его можно было повторно использовать как
декоратор:
@rules_light.make_decorator def some_condition (пользователь, правило, * args, ** kwargs): # делать что-нибудь rules_light.registry.setdefault ('ваше_приложение.ваша_модель.create', некоторое_условие) @some_condition def extra_condition (пользователь, правило,.
Приложение staticfiles | Документация Django
django.contrib.staticfiles
предоставляет три команды управления.
collectstatic
¶
-
django-admin collectstatic
¶
Собирает статические файлы в STATIC_ROOT
.
Повторяющиеся имена файлов по умолчанию разрешаются аналогично шаблону
разрешение работает: файл, который первым обнаружен в одном из указанных
локации будут использоваться.Если вы запутались, команда findstatic
может помочь показать вам, какие файлы были найдены.
При последующих запусках collectstatic
(если STATIC_ROOT
не пусто) файлы
копируются, только если их измененная временная метка больше, чем временная метка
файл в STATIC_ROOT
. Поэтому, если вы удалите приложение из INSTALLED_APPS
, рекомендуется использовать сборщик Опция --clear
для удаления устаревших статических файлов.
Поиск файлов осуществляется с помощью искателей
. По умолчанию поиск выполняется во всех местах, определенных в STATICFILES_DIRS
и в 'static' каталоге приложений
заданный параметром INSTALLED_APPS
.
Команда управления collectstatic
вызывает post_process ()
метод STATICFILES_STORAGE
после каждого запуска и проходит
список путей, найденных командой управления.Это также
получает все параметры командной строки collectstatic
. Это используется
с помощью ManifestStaticFilesStorage
по умолчанию.
По умолчанию собранные файлы получают разрешения от FILE_UPLOAD_PERMISSIONS
и собранные каталоги получают разрешения
из FILE_UPLOAD_DIRECTORY_PERMISSIONS
. Если вы хотите другого
разрешения для этих файлов и / или каталогов, вы можете создать подкласс любого из
статические классы хранения файлов и укажите file_permissions_mode
и / или directory_permissions_mode
параметров,
соответственно.Например:
из хранилища импорта django.contrib.staticfiles класс MyStaticFilesStorage (storage.StaticFilesStorage): def __init __ (self, * args, **.
Стиль кодирования | Документация Django
Пожалуйста, соблюдайте стиль отступов, указанный в .editorconfig
файл. Мы рекомендуем использовать текстовый редактор с поддержкой EditorConfig, чтобы избежать
проблемы с отступами и пробелами. В файлах Python используются 4 пробела для
отступы и файлы HTML используют 2 пробела.
Если не указано иное, следовать PEP 8 .
Используйте flake8, чтобы проверить наличие проблем в этой области. Обратите внимание, что наш файл setup.cfg файл содержит некоторые исключенные файлы (устаревшие модули, которые нам не нужны очистка и некоторый сторонний код, который поставщики Django), а также некоторые исключены ошибки, которые мы не рассматриваем как грубые нарушения. Помни это PEP 8 — это только руководство, поэтому уважайте стиль окружающего кода как Главная цель.
Исключением из PEP 8 являются наши правила относительно длин строк. Не ограничивайте строки
код до 79 символов, если это означает, что код выглядит значительно уродливее или
труднее читать.Мы допускаем до 119 символов, так как это ширина GitHub.
обзор кода; все, что длиннее, требует горизонтальной прокрутки, что делает обзор
труднее. Эта проверка включается при запуске flake8
. Документация,
комментарии и строки документов должны быть заключены в 79 символов, даже если PEP 8 предлагает 72.
Используйте четыре пробела для отступа.
Используйте четыре отступа для подвешивания вместо вертикального выравнивания:
поднять AttributeError ( "Вот многострочное сообщение об ошибке" 'сокращено для ясности.' )
Вместо:
поднять AttributeError ('Вот многострочное сообщение об ошибке' 'сокращено для ясности.')
Это позволяет лучше использовать пространство и позволяет избежать повторного выравнивания строк, если длина первой строки изменится.
Используйте одинарные кавычки для строк или двойные кавычки, если строка содержит одинарная кавычка. Не тратьте время на несвязанный рефакторинг существующего кода соответствовать этому стилю.
Избегайте использования «мы» в комментариях, например.грамм. «Зацикливаемся», а не «Зацикливаемся».
Используйте подчеркивания, а не верблюжий регистр, для имен переменных, функций и методов
(т.е. poll.get_unique_voters ()
, а не poll.getUniqueVoters ()
).
Используйте InitialCaps
для имен классов (или для заводских функций, которые
обратные классы).
В строках документации следуйте стилю существующих строк документации и PEP 257 .
В тестах используйте assertRaisesMessage ()
и assertWarnsMessage ()
вместо assertRaises ()
и assertWarns ()
, чтобы вы могли проверить
сообщение об исключении или предупреждении.Используйте assertRaisesRegex ()
и assertWarnsRegex ()
, только если вам нужен обычный
сопоставление выражений.
Используйте assertIs (…, True / False)
для тестирования
логические значения, а не assertTrue ()
и assertFalse ()
, поэтому вы можете проверить фактическое логическое значение
ценность, а не правдивость выражения.
В тестовых строках документации укажите ожидаемое поведение, которое демонстрирует каждый тест. Не включайте преамбулы, такие как «Проверяет, что» или «Обеспечивает это».
Ссылки на резервный билет для неясных проблем, когда в билете есть подробности, которые сложно описать в документации или комментариях. Включите номер билета в конце такого предложения:
def test_foo (): "" " Строка тестовой документации выглядит так (# 123456). "" " ...