Создание проекта HelloWorld

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

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

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

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

1 способ: когда указывается путь к конфигурационному классу приложения, добавим 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', # путь к конфигурационному классу нашего приложения
]

В данном примере путь blog.apps.BlogConfig, где blog приложение, apps - модуль(файл blog/apps.py), BlogConfig конфигурационный класс.

Такой способ позволяет задать имя используемого конфигурационного класса(их может быть несколько в файле apps.py) через файл настроек.

Код конфигурационного класса BlogConfig можно посмотреть в файле blog/apps.py, файл с ним был создан автоматически вместе с приложением. Давайте откроем этот файл и посмотрим на его содержимое:

from django.apps import AppConfig


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

2 способ: когда указывается только имя приложения, в данном случае blog:

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

При указании имени приложения Django ищет конфигурационный класс в файле apps.py данного приложения.

• Если там их несколько, то используется тот, у которого значение атрибута default = True.
• Если он один, то будет использоваться он, вне зависимости от значения атрибута default.
• Если нет ни одного, тогда будет использоваться базовый класс AppConfig из django.apps.

В большинстве случаев можно использовать 2й способ, указывая только имя приложения. Точный путь к конфигурационному классу следует использовать когда их несколько в файле apps.py, это удобнее чем устанавливать в файле apps.py атрибут default = True для нужного конфигурационного класса.

Не волнуйтесь, если на этом этапе вы запутались: чтобы понять, как устроены проекты и приложения 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!')

Мы импортируем класс HttpResponse из Django, чтобы мы могли его использовать в нашем коде. Функция представления ( homepageview ) принимает объект request, который содержит всю информацию о запросе. Далее мы создаем и возвращаем объект HttpResponse, передавая ему строку 'Hello, World!'. Эта строка, которая и будет отправлена в теле HTTP-ответа.

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

Django начинался с функциональных представлений (FBV), но затем были введены классовые представления (CBV), которые значительно улучшили переиспользование кода, позволили соблюдать принцип DRY и упростили расширение функциональности за счет миксинов. Дополнительная абстракция 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, для создания нашего нового маршрута, а в следующей строке мы импортируем наши представления.

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

Наш добавленный маршрут состоит из трех частей:

1. Шаблон URL адреса для корневой директории сайта ''.
2. Используемая функция-представление homepageview.
3. Имя маршрута home, это необязательный именованный параметр name функции path.

Другими словами, если пользователь запрашивает домашнюю страницу(корневую директорию сайта /), Djangoдолжен использовать представление под названием homepageview.

Более подробнее с диспетчером URL мы познакомимся в следующем разделе.

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

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

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
]

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

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

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

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

python manage.py runserver

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

​

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

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