Работа с представлениями и адресами.

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

Несмотря на то, что наше новое приложение существует в проекте Django, Django не "знает" о нем, пока мы явно не добавим его в файл Course_FirstProject/settings.py.

В текстовом редакторе откройте этот файл и прокрутите ниже до INSTALLED_APPS, где вы увидите шесть встроенных приложений Django. Добавим blog.apps.BlogConfig в самый низ:

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'blog.apps.BlogConfig' # наше новое приложение
]

Что такое BlogConfig, спросите вы? Это название единственного подкласса AppConfig в файле blog/apps.py на данный момент, которая автоматически была создана. Давайте откроем файл и проверим:

from django.apps import AppConfig


class BlogConfig(AppConfig):
    default_auto_field = 'django.db.models.BigAutoField'
    name = 'blog'

Также мы можем указывать в INSTALLED_APPS просто название нашего приложения, в нашем случае это blog:

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'blog'
]

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

Добавление Hello, World

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

• models.py

• views.py

• template.html (HTML файл шаблона)

• urls.py

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

Поэтому следующим шагом будет создание нашего первого представления. Начнем с обновления файла views.py в нашем приложении blog, чтобы он выглядел следующим образом:

blog/views.py:

from django.http import HttpResponse


def homepageview(request):
    return HttpResponse("Hello, World!")

По сути, мы говорим, что всякий раз, когда вызывается функция представления homepageview, возвращаем текст Hello, World!.

Более конкретно, мы импортировали встроенный метод HttpResponse, чтобы мы могли вернуть пользователю объект ответа.

Мы создали функцию homepageview, которая принимает объект запроса и возвращает ответ со строкой Hello, World!.

В Django существует два типа представлений: представления на основе функций (FBV) и представления на основе классов (CBV). Наш код в этом примере представляет собой представление на основе функций: оно относительно простое в реализации и явное.

Django изначально начинался только с FBV, но со временем были добавлены CBV, которые позволяют намного больше повторного использования кода, сохраняют принцип DRY(Don't-Repeat-Yourself), и могут быть расширены с помощью миксинов. Дополнительная абстракция CBVs делает их довольно мощными и лаконичными, однако это также делает их более сложными для чтения новичками в Django.

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

Таким образом, технически существует три способа написания представления в Django: представления на основе функций (FBVs), представления на основе классов (CBVs) и общие представления на основе классов (GCBVs). Эта настройка полезна для опытных разработчиков, но сбивает с толку новичков.

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

Далее нам нужно настроить наши URL-адреса. Создайте новый файл urls.py в приложении blog. Затем обновите его следующим кодом:

blog/urls.py:

from django.urls import path
from .views import homepageview

urlpatterns = [path("", homepageview, name="home"), ]

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

Ссылаясь на файл views.py как на .views, мы говорим Django искать в текущей директории файл views.py и импортировать оттуда представление homepageview.

Наш шаблон URL состоит из трех частей:

1. Регулярное выражение Python для пустой строки ""

2. Ссылка на представление под названием homepageview

3. Необязательный именованный шаблон URL с именем home

Другими словами, если пользователь запрашивает домашнюю страницу, представленную пустой строкой "", Django должен использовать представление под названием homepageview. Более подробнее с диспетчером URL мы познакомимся в следующем разделе.

На этом мы почти закончили. Последний шаг - это обновление нашего файла Cource_FirstProject/urls.py.

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

Cource_FirstProject/urls.py:

from django.contrib import admin
from django.urls import path, include  # new

urlpatterns = [
    path("admin/", admin.site.urls),
    path("", include("blog.urls")),  # new
]

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

Теперь каждый раз, когда пользователь заходит на домашнюю страницу, он будет сначала перенаправляться в приложение blog, а затем в представление homepageview, заданное в файле blog/urls.py. Именные пространства должны быть уникальными для всего проекта. Подробнее о пространствах имен для URL-запросов мы поговорим в следующих разделах.

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

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

# Windows

python manage.py runserver

# macOS

python3 manage.py runserver

Откройте в браузере http://127.0.0.1:8000/ и там появится Hello, World!, а не дефолтная страница Django:

В этом разделе мы рассмотрели множество фундаментальных концепций. Мы создали наше первое Django-приложение и узнали о структуре проекта/приложения Django. Мы начали изучать представления, урлы и внутренний веб-сервер Django.

Если у вас возникли трудности, вы можете клонировать проект с гитхаба - https://github.com/Permin0ff/Cource_FirstProject