Создание приложения в Django для начинающих | manage.py startapp

Создаем первое приложение в Django — Урок №2

Создание сайтов в Django

В данном уроке мы создадим простой сайт на Django, который будет выводить надпись «Hello World» на домашнюю страницу. Это классический старт изучения нового языка программирования или фреймворка. Мы также впервые поработаем с git и разместим код на GitHub.

Содержание статьи

Если возникнут сложности, можете ознакомиться с полным набором исходных кодов примеров текущей темы на хранилище GitHub.

> Есть вопросы по Python?
На нашем форуме вы можете задать любой вопрос и получить ответ от всего нашего сообщества!
Открыть форум

Начальная настройка Django-приложения

Первым делом переместимся в новую директорию. Например, можно создать директорию helloworld на рабочем столе, используя следующие инструкции.

Убедитесь, что в настоящий момент вы не находитесь ни в каком существующем виртуальном окружении. Здесь подсказкой станут скобки () перед знаком доллара ($). Для выхода из окружения наберите exit, после чего нажмите клавишу Enter. Пропавшие скобки — признак деактивации виртуального окружения.

Для создания нового виртуального окружения мы используем pipenv, затем установим Django и затем активируем его.

Если у вас Ubuntu, то увидите подтверждение изменений прямо сейчас — (helloworld). Название директории теперь взято в скобки и находится в строке перед командой. К сожалению, пользователи Windows на данном этапе не смогут увидеть никаких подтверждений активации.

Создадим новый проект Django под названием helloworld_project. В конце команды поставим точку (.) — тогда проект будет установлен в текущую папку.

Используйте команду tree и посмотрите на структуру созданного проекта Django. Если tree не сработала, наберите в командной строке: sudo apt install tree.

Файл settings.py контролирует настройки проекта, urls.py сообщает Django, какие страницы создать в ответ на запрос браузера или URL-адреса, а wsgi.py, что расшифровывается как Web Server Gateway Interface, помогает Django управлять конечными веб-страницами. Последний файл, manage.py, используется для выполнения различных команд Django. Это может быть запуск локального веб-сервера или создание нового приложения.

Django поставляется со встроенным локальным веб-сервером, который запускается командой runserver.

При переходе по адресу http://127.0.0.1:8000/ вам откроется следующая страница:

django app

Приветственная страница Django

Обратите внимание, что в полном результате вывода будет указана дополнительная информация, среди которой будет предупреждение о непримененных миграциях 17 unapplied migrations.

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

Тем не менее, чтобы предупреждение не мозолило глаза, мы можем удалить его. Для этого нужно остановить локальный сервер комбинацией CTRL+C, а затем выполнить команду python manage.py migrate.

Здесь Django осуществил миграцию встроенных приложений. Теперь при повторном выполнении python manage.py runserver командная строка выведет следующий чистый результат:

Создание приложения на Django 3

Для сохранения аккуратности и читабельности кода Django использует концепт проектов и приложений. Приложения внутри проекта влияют на производительность главного веб-приложения. Команда для создания нового приложения Django — startproject.

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

То, как и когда распределить функционал по приложениям, является субъективным понятием. Однако, в общем и целом у каждого приложения должна быть ясная функция.

Пришло время для создания первого приложения. Выйдите из командной строки при помощи CTRL+C. Затем наберите команду startapp с последующим названием приложения. В нашем случае это pages.

Если вы еще раз посмотрите на структуру директории при помощи команды tree, то заметите, что Django создал новую директорию pages, в которой расположены следующие файлы:

Посмотрим, за что отвечает каждый файл внутри папки pages:

  • admin.py является файлом конфигурации для встроенного приложения панели администратора Django;
  • apps.py является файлом конфигурации для самого приложения;
  • migrations отслеживает все изменения в файле models.py, поэтому наша база данных будет постоянно синхронизироваться с models.py;
  • models.py определяет модели нашей базы данных, которые Django автоматически переводит в таблицы базы данных;
  • tests.py нужен для специфических тестов приложения;
  • views.py являет местом, где обрабатываются логические запросы/ответы нашего веб-приложения.

Хотя созданное приложение существует внутри проекта Django, сам Django пока об этом «не знает», и наша задача просветить его. Через текстовый редактор откройте файл settings.py и найдите пункт INSTALLED_APPS, под которым будут указаны шесть изначально встроенных приложений Django. Добавьте новое приложение pages в самый низ.

Локальные приложения всегда добавляются в самый низ, так как Django задействует настройки INSTALLED_APPS сверху вниз. Это значит, что сначала грузится внутреннее приложение admin, затем auth и так далее. Важно, чтобы главные приложения Django были доступны, ведь созданные нами приложения будут полагаться на их функционал.

Некоторым может стать интересно, зачем прописывать такую длинную строчку pages.apps.PagesConfig, почему в список нельзя просто добавить название приложения pages?

Причина в том, что Django с каждым новым приложением создает файл apps.py, куда можно добавить дополнительную информацию, например, с фреймворка Signals, техника которого считается продвинутой. Для стабильной работы нашего простого приложения должно хватить pages, однако мы будем лишены дополнительных опций, поэтому внутри настроек INSTALLED_APPS будет лучше всегда использовать полное имя приложения с конфигурацией.

Если все вышесказанное показалось вам несколько запутанным, не переживайте. Для привыкания к структуре проектов и приложений Django нужна практика. На протяжении всего курса будем создавать множество проектов и приложений, что помогут приспособиться к принципам работы Django.

URL, представления (Views), модели (Models) и шаблоны (Templates)

В Django для оптимальной работы одной страницы требуется как минимум три (чаще четыре) файла. Внутри приложения этими файлами являются urls.py, views.py, models.py и HTML шаблон index.html.

Работа в Django строится на взаимодействии упомянутых выше элементов, однако новичков такая система может легко запутать, поэтому будет лучше сперва разобраться с порядком HTTP запросов/ответов. При вводе определенного URL, например, https://python-scripts.com, проект Django осуществляет попытку отыскать URL-паттерн, который бы соответствовал адресу домашней страницы. Данный URL-паттерн уточняет представление (view), которое определяет содержимое страницы (обычно на основании модели (model) базы данных) и в конечном итоге — шаблон (template) для стилей и базовой логики. Финальный результат отправляется пользователю назад в виде HTTP ответа.

Схему завершенного потока можно представить следующим образом:

Цикл работы Django запроса/ответа

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

Главная идея заключена в том, что представления Django определяют, какое содержимое отображается на странице, в то время как URLConfs отвечает за то, куда данное содержимое будет направлено. Модель включает в себя содержимое базы данных, а шаблон предоставляет стили.

Когда пользователь запрашивает некую страницу, например, домашнюю страницу, файл urls.py использует регулярное выражение для назначения данного запроса для подходящей функции представления, которая затем возвращает верные данные. Иными словами, наше представление выведет текст «Hello, World» в то время, как url должен будет убедиться в том, что во время всех визитов пользователя на домашнюю страницу отображаемое представление является верным.

Давайте посмотрим, как все работает. Для начала обновим файл views.py в приложении pages:

По существу, здесь мы заявляем, что когда бы функция представления homePageView ни была вызвана, ответом будет текст «Hello, World!». Говоря точнее, мы импортируем встроенный метод HttpResponse, и поэтому можем вернуть ответный объект пользователю. Мы создали функцию под названием homePageView, которая принимает объект запроса request и возвращает ответ response в виде строки «Hello, World!»

Теперь нам нужно настроить все url. Для этого в приложении pages создается новый файл urls.py.

Затем обновляем его при помощи следующего кода:

Верхняя строчка импортирует path из Django для усиления нашего URL-паттерна, а следующая за ней строка импортирует представления. Обращаясь к файлу views.py как .views мы просим Django обследовать текущую директорию в поисках файла views.py.

У нашего URLpatterns есть три составляющие:

  • регулярное выражение Python для пустой строки '';
  • отсылка к представлению под названием homePageView;
  • опциональный именованный URL паттерн 'home'.

Другими словами, если пользователь запрашивает домашнюю страницу, представленную пустой строкой '', тогда используется представление под названием homePageView.

На данный момент мы почти все разобрали. Последним шагом станет обновление файла helloworld_project/urls.py. Для одного проекта Django, в данном случае pages, типично иметь сразу несколько приложений, и у каждого должен быть свой собственный URL.

На второй строке возле path мы импортировали include, а затем создали новый URL-паттерн для приложения pages. Теперь любые визиты пользователя на домашнюю страницу вначале будут направлены к приложению pages, а затем к набору представления homePageView, что расположен в файле pages/urls.py.

Необходимость сразу в двух различных файлах urls.py часто запутывает начинающих. Здесь helloworld_project/urls.py верхнего уровня рассматривается как шлюз для многобразных url паттернов, различных для каждого приложения.

Приложение «Hello World» в Django

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

Если вы обновите в браузере страницу http://127.0.0.1:8000/, на экране отобразится текст «Hello, World!»

app hello world

Домашняя страница Hello world

Использование Git для загрузки кода на Github

Git является системой управления версиями. Сейчас мы ее используем. Первым шагом станет инициализация (или добавление) git в наше хранилище.

Теперь, если вы наберете git status, то увидите список изменений с момента последнего коммита. Ввиду того, что текущий коммит является первым, список примет следующий вид.

Далее мы добавим все изменения, используя команду add -A, затем commit для их подтверждения, а после этого применим (-m) для описания изменений.

Работа с GitHub при создании сайта на Django

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

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

Для использования GitHub необходимо зарегистрироваться и получить бесплатный аккаунт на домашней странице сайта. Затем вас попросят решить небольшой паззл — это требуется для отвода автоматических регистраций ботами.

github

Проверка GitHub

Затем требуется подтвердить бесплатную подписку, что является выбором по умолчанию. Нажмите на кнопку «Continue» в нижней части страницы.

github

Подписка GitHub 

На третьем этапе вас попросят ответить на несколько вопросов для обозначения вашего уровня разработчика и причины работы с GitHub. Отметьте где нужно галочки или же пропустите данный пункт, выбрав «Skip this step» внизу страницы.

github

Настройка GitHub

На последней странице вас попросят подтвердить адрес электронной почты. Вам должно прийти письмо от GitHub, внутри будет ссылка, перейдя по которой вы вернетесь на GitHub, будучи зарегистрированным пользователем.

Создадим наше первое хранилище на https://github.com/new.

github

Новое хранилище на GitHub

Введите название хранилища hello-world и отметьте его вид — в данном случае это «Private», а не «Public». Затем подтвердите действия, нажав кнопку «Create Repository» внизу страницы.

Ваше первое хранилище создано! Однако оно пока пустое. Пролистайте страницу ниже и найдите “…or push an existing repository from the command line”. Это то, что нам нужно.

github

Хранилище Hello, World на GitHub

Скопируйте текст под заголовком и вставьте его в командную строку. Я использовал имя пользователя stillriverpress, следовательно вы вписываете свое имя — в противном случае команда не сработает. Данная операция синхронизирует локальную директорию на компьютере с удаленным хранилищем на GitHub.

На последнем этапе нам нужно загрузить данные на GitHub при помощи команды push.

Если все сработало верно, то, вернувшись на страницу GitHub и перезагрузив ее, вы увидите, что там появилась копия вашего кода.

Настройка SSH ключей для работы с Github

К сожалению, если вы начинающий разработчик и еще не настроили SSH ключи, то в ответ на предыдущую команду может выйти ошибка.

Появление данного загадочного сообщения говорит о том, что нам нужно настроить SSH ключи. Дело хоть и на один раз, но, по правде говоря, оно несколько хлопотно.

SSH является протоколом, который используется для подтверждения личных связей с удаленным сервером. Рассматривайте его как дополнительный слой защиты поверх системы логина/пароля. Процесс включает в себя генерацию уникальных ключей SSH и последующее хранение их на вашем компьютере, таким образом внешний доступ к ним будет только у GitHub.

Первым делом проверьте, есть ли у вас ключи SSH. У GitHub предусмотрен для этого специальный гид, который работает на Mac, Windows и Linux. Если у вас нет публичных и личных ключей, вам нужно будет сгенерировать их. У GitHub и для этого есть гид.

Теперь по завершении процесса генерирования ключей вы наверняка сможете успешно выполнить команду git push -u origin master.

Не стоит расстраиваться, если разобраться с ключами SSH не выйдет с первого раза. У GitHub есть много материала, связанного с данной темой, так как на начальном этапе подобающее большинство пользователей сталкиваются с некоторыми сложностями. Если исправить ошибки на данном этапе никак не получается, оставьте пока ключи, вздремните, а затем, выспавшись, возвращайтесь к GitHub и ключам SSH. Хороший сон очень часто помогает разобраться с проблемами, это не шутка. Отдохнув, я зачастую справлялся с довольно сложными программами.

Небольшое видео на Youtube вам может помочь.

Успешно разобравшись с GitHub, двинемся дальше и выйдем и виртуального окружения при помощи команды exit.

О деактивации виртуального окружения сообщит отсутствие скобок в командной строке.

Заключение

Поздравляю! Нам удалось разобрать много фундаментально важных концептов. Мы создали первое приложение Django и познакомились со структурой проектов/приложений Django. Мы также приступили к изучению представлений, url и внутреннего сервера Django. Мы также поработали с git, проследили за изменениями и разместили наш код в личном хранилище GitHub.