Как создать наше первое приложение на нашем веб-сайте Django

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

Хорошо, отлично. Давайте продолжим и запустим ваш сервер прямо сейчас. Для этого мы будем использовать manage.py. Было бы лучше открыть отдельный терминал/командную строку для запуска сервера. Обычно при разработке нашего веб-сайта сервер работает в фоновом режиме.

Чтобы запустить сервер, запустите это::

python manage.py runserver

Вы должны увидеть что-то вроде:

Мы можем пока игнорировать миграцию; мы поговорим об этом позже. Теперь мы должны увидеть, что наш сервер разработки в настоящее время работает по адресу http://127.0.0.1:8000. Откройте браузер и перейдите по этому адресу. Вы должны увидеть очень похожее представление на следующее:

Это всего лишь шаблон Django по умолчанию (мы видели его в первом уроке), который уже объединен с библиотекой Django, если вы еще не работаете с домашней страницей самостоятельно. Мы заменим этот шаблон на свой. Как я уже говорил, с этого момента я оставлю сервер работающим в фоновом режиме.

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

• Модель: абстракция базы данных, содержащая объекты, сопоставленные с базой данных вашего сервера. Например, у нас будет модель/объект «Tutorial Series», модель/объект «Tutorial», модель/объект «User» и т. д. Вам нужно определить эти модели, а Django сделает все остальное за нас. Вы даже можете изменить свои модели, и после применения миграции Django может помочь вам управлять изменениями базы данных за секунды, а не за ожидаемый час или более, которые вам пришлось бы делать самостоятельно вручную;
• Вид: как вы будете представлять данные. Здесь вы будете отображать и визуализировать вещи для пользователя;
• Контроллер: описывает, как ваши URL-адреса связаны с представлениями.

Хотя мы называем это MVC (модель, представление, контроллер), вы можете себе представить, что это наоборот. Пользователь перейдет по URL-адресу, а контроллер (urls.py) укажет конкретное представление (views.py). И тогда это представление может быть (необязательно) связано с вашими моделями.

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

Регистрация основного приложения:

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

Откройте файл настроек проекта, django_project/django_website/settings.py, и найдите определение списка INSTALLED_APPS. Затем в конце списка добавьте новую строку, как показано ниже:

В новой строке указывается объект конфигурации программы (Основной), сгенерированный для вас at /django_website/main/apps.py при создании приложения.

Примечание. Вы можете заметить, что INSTALLED_APPS намного больше (и MIDDLEWARE в файле настроек). Они обеспечивают поддержку сайта администрирования Django и используемых им функций (включая аутентификацию, сеансы и т. д.).

Указание базы данных:

Здесь также необходимо указать базу данных проекта. Рекомендуется по возможности использовать одну и ту же базу данных для разработки и производства, чтобы избежать незначительных различий в поведении. Вы можете узнать о различных опциях и возможностях в официальной документации Django о Базах данных.

Мы будем использовать базу данных SQLite для этого проекта, потому что мы не ожидаем, что у нас будет много одновременных доступов к базе данных разработки, хотя для ее настройки не требуется никаких дополнительных действий! Вы можете увидеть, как легко настроить базу данных в settings.py:

Поскольку мы используем SQLite, здесь не требуется никаких других настроек. Когда мы переместим наш веб-сайт на рабочий сервер в будущих руководствах, я покажу вам, как перенести SQLite в базу данных PostgreSQL (одна из лучших баз данных с открытым исходным кодом). Давай продолжим!

Другие настройки проекта

Файл settings.py также используется для настройки некоторых других параметров. Однако вы, вероятно, хотите изменить только TIME_ZONE в это время, которое должно быть равно строке из стандартного Списка часовых поясов базы данных tz (столбец TZ в таблице содержит нужные вам значения). Измените значение TIME_ZONE на одну из следующих строк для вашего часового пояса. Например, TIME_ZONE = "Европа/Лондон". Но вы можете оставить UTC по умолчанию для разработки.

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

• СЕКРЕТ_КЛЮЧ. Этот секретный ключ используется как часть политики безопасности веб-сайта Django. Если вы не сохраните этот код при разработке, вам потребуется использовать другой код (возможно, считанный из переменной среды или файла) для безопасного запуска производственного сервера;
• ОТЛАДКА. Это позволяет отображать журналы отладки вместо ответов кода состояния HTTP. В рабочей среде для этого параметра следует установить значение False, поскольку отладочная информация полезна для хакеров и злоумышленников, но пока мы можем оставить его равным True.

Когда мы развернем наш веб-сайт на рабочем сервере, мы вернемся к этим настройкам.

Подключение сопоставления URL

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

Откройте django_project/django_website/urls.py и обратите внимание на текст с инструкциями, в котором объясняются некоторые способы использования преобразователя URL:

Сопоставление URL обрабатывается с помощью переменной urlpatterns, которая представляет собой список функций Python path(). Каждая функция path() связывает шаблон URL с определенным представлением, которое будет отображаться при совпадении шаблона. Первоначально список шаблонов URL-адресов представляет собой единую функцию, которая связывает все URL-адреса с шаблоном «admin» с модулем «admin.site.URLs», который содержит определения сопоставления URL-адресов административной программы.

Примечание. Маршрут в функции path() представляет собой строку, определяющую URL-адрес, соответствующий шаблону. Этот шаблон будет соответствовать URL-адресу, такому как /main/any_chars/, и передать «any_chars» в представление в виде строки, где имя параметра — «id». Эта строка может иметь имя переменной (в угловых скобках), например. 'main/<id>/'. Мы обсудим методы пути и шаблоны маршрутов в последующих статьях.

Итак, у нас есть только один URL-адрес здесь и, по-видимому, на какую-то административную страницу, на которую мы в данный момент не обращаем внимания. Наша цель — указать новый URL-адрес представления. Кстати, Django видит веб-сайт как набор приложений. Таким образом, файл urls.py внутри вашего «основного» приложения большую часть времени будет указывать на ваши приложения. Как мы указываем на приложение? Мы указываем на файл urls.py этого приложения! Итак, добавим, что:

Помимо добавления дополнительного пути, не забудьте импортировать «include» из django.urls. Хорошо, теперь Django знает, что когда заданный путь пуст (домашняя страница), просмотрите файл urls.py для основного приложения, чтобы увидеть, указывает ли этот файл (контроллер) на представление, которое будет выполнять какую-либо функцию внутри файла views.py.

Прежде чем продолжить, я должен упомянуть, что Django по умолчанию не поддерживает статические файлы, такие как CSS, JavaScript и изображения, но это может быть полезно для веб-сервера разработки при создании вашего сайта. Добавив этот обработчик URL-адресов, вы можете включить отрисовку статических файлов, добавив их, чтобы сделать окончательный urls.py. Файл будет выглядеть следующим образом:

Мы используем оператор «if debugging», потому что все эти файлы обрабатываются по-разному в производственной среде. Когда мы переместим наш веб-сайт на рабочий сервер, мы придем к ним.

Нам еще предстоит изменить/создать файл urls.py нашего основного приложения, и мы не делали никаких представлений. Сделаем оба! Давайте перейдем в наше приложение django_project/main. Мы видим, что здесь уже есть разные вещи, но нет urls.py! Здесь мы будем добавлять наши «основные» шаблоны приложений по мере их создания. Добавим это сейчас:

Мы импортируем path так же, как и раньше. Позже это станет полезным, когда мы хотим динамически ссылаться на URL-адреса). Как я уже сказал, Django очень модульный, и даже если вы собираетесь изменить URL-пути или использовать чужое приложение, но, возможно, используете разные URL-пути — вы можете сделать это без особых усилий. По этой причине мы также указываем имя в качестве параметра пути.

Теперь у нас есть все для запуска контроллера. Когда кто-то посещает домашнюю страницу, Django сначала смотрит на Django_project/django_website/urls.py, видя, что он указывает на django_project/main/urls.py, который затем указывает на views.homepage (функция, называемая домашней страницей внутри views.py). views.py здесь уже существует, но у нас там нет функции домашней страницы. Однако откройте его, чтобы создать один:

Как правило, эти представления будут выполнять за нас определенные специфические функции и возвращать некий отрендеренный HTML-шаблон и передавать некоторые переменные, но сейчас мы упростим их и пока будем возвращать прямой HTTP-ответ.

Тестирование фреймворка сайта:

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

Прежде чем сделать это, мы должны сначала запустить миграцию базы данных. Это обновляет нашу базу данных (чтобы включить все модели в наши установленные приложения) и удаляет некоторые предупреждения разработки.

Запуск миграции базы данных:

Django использует Object Relationship Mapper (ORM) для связывания определений модели в коде Django со структурой данных, используемой в базе данных. Django отслеживает изменения и может создавать сценарии миграции базы данных (в нашем примере: /django_project/main/migrations/) для автоматической миграции первичной структуры данных в базе данных в соответствии с моделями. Например, во Flask нам приходилось создавать эти переводы вручную.

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

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

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

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

Запуск веб-сайта:

При разработке веб-сервера Django настоятельно рекомендуется запускать его на локальном компьютере и просматривать в локальном браузере. Веб-сервер разработки недостаточно производительен или надежен для использования в качестве производственного сервера. Тем не менее, это простой способ настроить и запустить ваш веб-сайт Django во время разработки, чтобы обеспечить его удобный быстрый просмотр и тестирование. По умолчанию он будет запускать сервер на IP-адресе вашего локального компьютера (http://127.0.0.1:8000/), но если у вас достаточно знаний, вы также можете указать для этого другие компьютеры в вашей сети.

Если вы не запускаете его в фоновом режиме, давайте запустим его с помощью команды python manage.py runserver (в том же каталоге, что и manage.py). Теперь вернитесь в браузер и обновите его. Теперь на главной странице вы должны увидеть текст:

This is our homepage! It works!

Заключение:

Я остановлюсь здесь и предлагаю вам убедиться, что вы можете сделать все вышеперечисленное без использования учебника (так же, как в предыдущей части учебника). Итак, запустите новый проект, добавьте приложение, настройте файлы url.py так, чтобы домашняя страница указывала на представление, и это представление возвращало простую строку. Все станет еще сложнее, поэтому вам нужно понять эти основы. Не стесняйтесь использовать Google, если у вас возникли проблемы в какой-то момент.

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

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

Эти обучающие файлы можно скачать отсюда:

Первоначально опубликовано на https://pylessons.com/django-first-app

Дополнительные материалы на PlainEnglish.io. Подпишитесь на нашу бесплатную еженедельную рассылку новостей. Подпишитесь на нас в Twitter и LinkedIn. Присоединяйтесь к нашему сообществу Discord.