Советы для джанго

Курсы для web-разработчика на Python Django

Много материалов по Python Django есть в свободном доступе. Тем, кто знаком с языком программирования Python и основами, достаточно изучить официальную документацию фреймворка и туториал для новичков. А людям, которые далеки от программирования, лучше сначала пройти онлайн-курс под руководством преподавателя — это поможет постичь азы, чтобы двигаться дальше в верном направлении.

Есть платные и бесплатные онлайн и очные курсы, видеолекции, книги, интернет-ресурсы. Дистанционные курсы длятся от месяца до полугода в зависимости от того, насколько насыщенная программа. Стоит обучение от 15–20 тыс. рублей. Многие онлайн-университеты выдают выпускникам, успешно защитившим дипломную работу, диплом международного образца и помогают в трудоустройстве.

Какими знаниями и навыками должен обладать будущий Django-разработчик

Минимальный пакет знаний junior Django-разработчика включает:

  • основы HTML для web-ресурсов;
  • Python, его структуры данных и библиотеки;
  • jQuery, CSS, Git, IDE или редактор кода;
  • английский язык (нужен для чтения документации, статей), но для начала достаточно уметь читать со словарем.

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

Что нужно, чтобы стать junior Django:

Какие учебники и пособия будут полезны Django-программисту

Чтобы получить начальное понимание общих методов программирования и языка Python стоит изучить уроки Learn Python the Hard Way (есть на русском языке) или Google’s python class. Learn Python the Hard Way имеет смысл изучать до 42 урока — далее описываются достаточно сложные вещи, которые на начальном уровне не нужны. В Google’s python class желательно делать каждое упражнение, не подсматривая в ответы.

Программисты советуют новичкам книги:

  • Марк Лутц «Изучаем Python» (4-е издание);
  • Марк Лутц «Программирование на Python»;
  • Чед Фаулер «Программист-фанатик»;
  • Билл Любанович «Простой Python»;
  • Бен Форт «Освой самостоятельно SQL»;
  • Ultimate Django (пошаговые уроки по созданию приложения);
  • Джон Дакетт «HTML и CSS. Разработка и дизайн веб-сайтов»;
  • руководство TaskBuster Django Tutorial (на английском);
  • Дэвид Флэнаган «JavaScript. Подробное руководство».

Для начального понимания фреймворка достаточно освоить официальный учебник и документацию. Лучше сделать это дважды, чтобы понять, как взаимосвязаны все части. Легко подана информация на ресурсе Django Girls Tutorial (есть перевод на русский).

Более глубокое понимание Python дадут курсы Udacity’s intro CS class или Unit 1 of MIT’s intro CS course. Эти ресурсы почти взаимозаменяемы. После можно начинать практиковаться в создании простых приложений.

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

Курсы Django Python для начинающих

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

Необходимо сразу найти курс, где минимум 80 % времени уделено практике

Также желательно, чтобы обучение проводил практикующий разработчик уровня не ниже senior.

Как найти подходящий Django-видеокурс в Интернете

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

Для углубленного изучения и понимания сложных тем можно дополнительно находить отдельные видеолекции.

Возможно ли освоить Django Python за 1 час:

Ресурсы по Django REST

  • Обзор «Как разрабатывать API при помощи фреймворка Django REST» (How to Develop APIs with Django REST Framework) описывает все шаги по созданию API при помощи Django REST, начиная со среды разработки. В обзоре используется подход под названием «Разработка через тестирование» (test-driven development, TDD).
  • Официальное руководство — это один из лучших источников информации для любого проекта с открытым исходным кодом. Также много полезной информации можно найти на официальном сайте фреймворка.
  • Django: создание REST API — это первая часть великолепной серии статей про данный фреймворк (DRF). Вот остальные части:

    • Знакомимся с DRF (Django REST Framework: Getting Started).
    • Сериализаторы (Django REST Framework: Serializers).
    • Сериализаторы моделей и генераторы представлений (Django REST Framework: ModelSerializer and Generic Views).
    • ViewSet, ModelViewSet и маршрутизаторы (Django REST Framework: ViewSet, ModelViewSet and Router).
    • Аутентификация и разрешения (Django REST Framework: Authentication and Permissions).
    • JSON веб-токены (Django REST Framework: JSON Web Tokens (JWT)).
  • Статья «Как оптимизировать ваши представления Django REST» (How to Optimize Your Django REST Viewsets) дает пошаговую инструкцию (с конкретными примерами), как избежать большого количества ненужных запросов, используя методы  и  в слоях Django ORM.
  • Как сохранить дополнительные данные в сериализаторе Django REST ( How to Save Extra Data to a Django REST Framework Serializer)  — это краткое и удобное руководство для объединения дополнительных данных с уже определенными полями сериализатора DRF перед сохранением всего в базу данных или аналогичным действием.
  • Интерфейс запросов в Django REST Framework (Django polls api using Django REST Framework) — это отличное руководство по созданию серверной части приложения для запросов (пошаговый разбор кода прилагается).
  • Статья «Глубокий разбор классов permission в Django REST Framework» (Django REST Framework Permissions in Depth) содержит примеры кода и объясняет разницу между классами permission и authentication.
  • Оптимизация производительности Django REST Framework (Optimizing slow Django REST Framework performance).
  • Сериализация данных авторизованных пользователей в Django REST Framework (TLT: Serializing Authenticated User Data With Django REST Framework).
  • Создание API и представлений на основе классов с помощью Django REST Framework (Building an API with Django REST Framework and Class-Based Views).
  • Простой вложенный API с использованием Django REST Framework (Simple Nested API Using Django REST Framework)
  • Создание API в Django и Django Rest Framework (Building APIs with Django and Django Rest Framework)

Создание моделей¶

Теперь, после создания окружения (проекта), мы можем приступить к работе.

Каждое приложение Django состоит из пакета Python, который следует некоторым соглашениям. Django содержит команду, которая создает структуру для нового приложения, что позволяет вам сосредоточиться на написании кода, а не на создании каталогов.

Проекты или приложения

Какая разница между приложением и проектом? Приложение – это Web-приложение, которое предоставляет определенный функционал – например, Web-блог, хранилище каких-то записей или простое приложение для голосования. Проект – это совокупность приложений и конфигурации сайта. Проект может содержать несколько приложений. Приложение может использоваться несколькими проектами.

Ваше приложение может находиться где угодно в . В этом учебнике, мы будем создавать приложение голосования возле файла manage.py, и оно может быть импортировано как независимый модуль, а не подмодуль mysite.

Создавая приложение, убедитесь, что вы находитесь в том же каталоге, что и файл manage.py, и выполните команду:

$ python manage.py startapp polls

Эта команда создаст каталог polls:

polls/
    __init__.py
    admin.py
    migrations/
        __init__.py
    models.py
    tests.py
    views.py

Эти файлы являются частью приложения голосования.

Первый шаг в создании Web-приложения с БД в Django – это создание его моделей, которые являются, по сути, схемой базы данных с дополнительными метаданными.

Философия

Модель — это основной источник данных. Он содержит набор полей и поведение данных, которые вы храните. Django следует . Смысл в том, чтобы определять модели в одном месте.

Частью работы с данными также являются миграции. В отличии от Ruby On Rails, например, миграции вынесены из файла моделей и являются просто историей, которую Django может использовать для изменения базы данных в соответствии с текущей структурой моделей.

В нашем простом приложении голосования, мы создадим две модели: Question и Choice. Question содержит вопрос и дату публикации. Choice содержит: текст ответа и количество голосов. Каждый объект Choice связан с объектом Question.

Эти понятия отображаются простыми классами Python. Отредактируйте файл polls/models.py, чтобы он выглядел таким образом:

polls/models.py

from django.db import models


class Question(models.Model):
    question_text = models.CharField(max_length=200)
    pub_date = models.DateTimeField('date published')


class Choice(models.Model):
    question = models.ForeignKey(Question)
    choice_text = models.CharField(max_length=200)
    votes = models.IntegerField(default=)

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

Каждое поле представлено экземпляром класса – например, для текстовых полей и для полей даты и времени. Это указывает Django какие типы данных хранят эти поля.

Названия каждого экземпляра (например, question_text или pub_date ) это название поля, в “машинном”(machine-friendly) формате. Вы будете использовать эти названия в коде, а база данных будет использовать их как названия колонок.

Вы можете использовать первый необязательный аргумент конструктора класса , чтобы определить отображаемое, удобное для восприятия, название поля. Оно используется в некоторых компонентах Django, и полезно для документирования. Если это название не указано, Django будет использовать “машинное” название. В этом примере, мы указали отображаемое название только для поля Question.pub_date. Для всех других полей будет использоваться “машинное” название.

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

может принимать различные необязательные аргументы; в нашем примере мы указали значение для votes` равное 0.

Установка Django

Теперь у нас все
готово для установки самого фреймворка Django в созданное
виртуальное окружение. Так как я в своей работе использую интегрированную среду
PyCharm, то дальнейшие
действия по работе с виртуальным окружением буду делать через нее. Уверен, что
большинство из вас тоже пользуются PyCharm, поэтому все
должно быть предельно понятно. Итак, открываем созданный проект, указав папку:

D:/Python/django/djsite

и после
индексирования всех файлов интегрированная среда автоматически активизирует
установленное виртуальное окружение. Если это по каким-то причинам не
произошло, то нужно вручную указать PyCharm это окружение.
Для
этого следует перейти на вкладку Project Interpreter:

File
-> Settings -> Project:djsite -> Project Interpreter

и указать
интерпретатор из установленного окружения.

Далее, находясь
в корневой папке проекта, мы должны выполнить непосредственно установку Django с помощью
очевидной команды:

pip install
django

После этого в
наше виртуальное окружение будет устанавливаться данный фреймворк со всеми
необходимыми зависимостями. Если теперь выполнить команду:

pip list

то мы увидим
последнюю рабочую версию Django и несколько дополнительных
пакетов, необходимых для его работы.

Но это лишь ядро
фреймворка с общим функционалом. Используя это ядро, мы можем создавать
множество разных сайтов под управлением Django в рамках
текущего виртуального окружения. Чтобы посмотреть список команд ядра,
достаточно в терминале записать:

django-admin

Так вот, для
создания нашего первого сайта, нам понадобится команда startproject, которая
записывается так:

django-admin
startproject <имя сайта>

Здесь «имя
сайта», обычно, является доменным именем. Например, если мы собираемся
располагать сайт на домене:

coolsite.ru

то в качестве
имени логично выбрать coolsite. Давайте так и сделаем, выполним команду:

django-admin
startproject coolsite

Давайте теперь
запустим тестовый веб-сервер на нашем локальном компьютере и убедимся, что
созданный сайт работает. Для этого перейдем в папку coolsite:

cd coolsite

и выполним файл manage.py с командой runserver:

python manage.py
runserver

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

Ctrl + Break (а также Ctrl + C в Windows)

а, затем, снова
запустить:

python manage.py
runserver

Также обратите
внимание, что при первом запуске сервера в проекте появился еще один файл db.sqlite3 – файл БД SQLite3. Дело в том,
что по умолчанию Django использует именно такую СУБД

В
дальнейшем, мы можем это изменить и указать любую другую СУБД, которую
поддерживает данный фреймворк. Это может быть:

PostgreSQL, MariaDB, MySQL, Oracle и SQLite

Но вернемся к
запуску сервера. Его можно запускать также и со следующими параметрами:

python
manage.py runserver 4000

или так:

python manage.py runserver
192.168.1.1:4000

Я, надеюсь, из
этого занятия вы поняли, что из себя представляет фреймворк Django, как он
устанавливается, как создать проект нового сайта и как проверить его
работоспособность с помощью тестового веб-сервера.

Видео по теме

#1. Django — что это такое, порядок установки

#2. Модель MTV. Маршрутизация. Функции представления

#3. Маршрутизация, обработка исключений запросов, перенаправления

#4. Определение моделей. Миграции: создание и выполнение

#5. CRUD — основы ORM по работе с моделями

#6. Шаблоны (templates). Начало

#7. Подключение статических файлов. Фильтры шаблонов

#8. Формирование URL-адресов в шаблонах

#9. Создание связей между моделями через класс ForeignKey

#10. Начинаем работу с админ-панелью

#11. Пользовательские теги шаблонов

#12. Добавляем слаги (slug) к URL-адресам

#13. Использование форм, не связанных с моделями

#14. Формы, связанные с моделями. Пользовательские валидаторы

#15. Классы представлений: ListView, DetailView, CreateView

#16. Основы ORM Django за час

#17. Mixins — убираем дублирование кода

#18. Постраничная навигация (пагинация)

#19. Регистрация пользователей на сайте

#20. Делаем авторизацию пользователей на сайте

#21. Оптимизация сайта с Django Debug Toolbar

#22. Включаем кэширование данных

#23. Использование капчи captcha

#24. Тонкая настройка админ панели

#25. Начинаем развертывание Django-сайта на хостинге

#26. Завершаем развертывание Django-сайта на хостинге

Пишем тесты для Django приложений

Наконец-то мы добрались до тестов

Хотя в приложениях это является базовым концептом, очень важно, чтобы добавление тестов в Django вошло у вас в привычку. Цитируя Джейкоба Каплан-Мосса, одного из создателей Django: «Непротестированный код можно считать сломанным«

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

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

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

Python

# pages/tests.py
from django.test import SimpleTestCase

class SimpleTests(SimpleTestCase):
def test_home_page_status_code(self):
response = self.client.get(‘/’)
self.assertEqual(response.status_code, 200)

def test_about_page_status_code(self):
response = self.client.get(‘/about/’)
self.assertEqual(response.status_code, 200)

1
2
3
4
5
6
7
8
9
10
11
12

# pages/tests.py

fromdjango.testimportSimpleTestCase

classSimpleTests(SimpleTestCase)

deftest_home_page_status_code(self)

response=self.client.get(‘/’)

self.assertEqual(response.status_code,200)

deftest_about_page_status_code(self)

response=self.client.get(‘/about/’)

self.assertEqual(response.status_code,200)

База данных нам пока не нужна, поэтому сейчас можно использовать простой . При наличии базы данных нужно обратиться к . Затем проводится проверка, в результате которой у каждой страницы должен быть код состояния 200 — это успешный ответ на стандартный HTTP запрос. Таким образом, становится понятно, что запрашиваемая страница действительно существует, но при этом не раскрывается ее содержимое.

Для запуска теста остановите веб-сервер, использовав комбинацию , а затем наберите в командной строке :

Shell

(pages) $ python manage.py test
Creating test database for alias ‘default’…
System check identified no issues (0 silenced).
..
———————————————————————-
Ran 2 tests in 0.014s

OK
Destroying test database for alias ‘default’…

1
2
3
4
5
6
7
8
9

(pages)$python manage.pytest

Creating testdatabase foralias’default’…

System check identified no issues(silenced).

..

———————————————————————-

Ran2tests in0.014s

 
OK

Destroying testdatabase foralias’default’…

Все успешно! В будущем мы будем использовать более сложные тесты, особенно это важно при работе с базами данных

Проектирование шаблонов¶

Код, представленный выше, возвращает шаблон .

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

Скажем, шаблон был найден. Вот как он может выглядеть:

mysite/news/templates/news/year_archive.html

{% extends "base.html" %}

{% block title %}Articles for {{ year }}{% endblock %}

{% block content %}
<h1>Articles for {{ year }}</h1>

{% for article in article_list %}
    <p>{{ article.headline }}</p>
    <p>By {{ article.reporter.full_name }}</p>
    <p>Published {{ article.pub_date|date:"F j, Y" }}</p>
{% endfor %}
{% endblock %}

Переменные всегда окружены двумя фигурными скобками. означает «вывести переменную, хранящую заголовок статьи.» Хотя точка используется не только для доступа к атрибутам: с её помощью можно провести поиск в словаре, поиск индекса и вызов функции.

Примечательно, что использует Unix-стиль «pipe» (символ вертикальной черты «|»). Это называется шаблонным фильтром и это хороший способ для фильтрации значений переменной. В примере фильтр даты приводит объект datetime к нужному виду (как нахождение функции даты в PHP).

Вы можете последовательно применить столько фильтров, сколько вам будет нужно. Вы можете писать . Вы можете писать собственные шаблонные теги, которые будут неявно выполнять ваш код.

Наконец, Django использует концепцию «наследования шаблонов»: это достигается путём включения базового шаблона . И это значит, что первым будет загружен шаблон „base“, в котором определено множество различных блоков, которые в свою очередь также могут содержать в себе какие-то блоки. Короче говоря, это позволяет намного сократить количество html-шаблонов страниц: каждый новый шаблон должен включать уникальные элементы, присущие только ему.

Базовый шаблон «base.html», включающий использование статических файлов, может выглядеть следующим образом:

mysite/templates/base.html

{% load static %}
<html>
<head>
    <title>{% block title %}{% endblock %}</title>
</head>
<body>
    <img src="{% static "images/sitelogo.png" %}" alt="Logo">
    {% block content %}{% endblock %}
</body>
</html>

Simplistically, it defines the look-and-feel of the site (with the site’s logo),
and provides «holes» for child templates to fill. This means that a site redesign
can be done by changing a single file – the base template.

It also lets you create multiple versions of a site, with different base
templates, while reusing child templates. Django’s creators have used this
technique to create strikingly different mobile versions of sites by only
creating a new base template.

Установка Django через pipenv

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

Shell

$ cd ~/Desktop
$ mkdir django
$ cd django

1
2
3

$cd~Desktop

$mkdirdjango

$cddjango

Теперь используем Pipenv для инсталляции Django.

Shell

$ pipenv install django==3.0

1 $pipenv install django==3.0

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

Shell

$ pipenv shell

1 $pipenv shell

При работе на Ubuntu вы увидите, что название текущей директории в командной строке взято в скобки. Это значит, что виртуальное окружение активировано. Будучи внутри папки , перед знаком командной строки мы увидим .

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

Shell

(django) $

1 (django)$

Все работает! Теперь создаем новый проект Django под названием при помощи следующей команды. Не забудьте в конце поставить точку.

Shell

(django) $ django-admin startproject test_project .

1 (django)$django-admin startproject test_project.

Немного остановимся на причине использования точки (.) в предыдущей команде. Если вы просто запустите то Django по умолчанию создаст следующую структуру:

Структура

Shell

└── test_project
├── manage.py
└── test_project
├── __init__.py
├── settings.py
├── urls.py
└── wsgi.py

1
2
3
4
5
6
7

└──test_project

├──manage.py

└──test_project

├──__init__.py

├──settings.py

├──urls.py

└──wsgi.py

Как видите, создается новая директория , в ней файл и еще одна директория . Чувствуется повторение, ведь ранее мы уже создали директорию на рабочем столе и переместились в нее. Будет лучше выполнить команду с точкой на конце. Это нужно для установки в данную конкретную папку — на сей раз результат будет таков:

Структура 

Shell

├── manage.py
└── test_project
├── __init__.py
├── settings.py
├── urls.py
└── wsgi.py

1
2
3
4
5
6

├──manage.py

└──test_project

├──__init__.py

├──settings.py

├──urls.py

└──wsgi.py

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

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

Shell

(django) $ python manage.py runserver

1 (django)$python manage.pyrunserver

Мы получим такой ответ:

Shell

Watching for file changes with StatReloader
Performing system checks…

System check identified no issues (0 silenced).

You have 17 unapplied migration(s). Your project may not work properly until you apply the migrations for app(s): admin, auth, contenttypes, sessions.
Run ‘python manage.py migrate’ to apply them.

May 05, 2020 — 12:36:09
Django version 3.0, using settings ‘test_project.settings’
Starting development server at http://127.0.0.1:8000/
Quit the server with CONTROL-C.

1
2
3
4
5
6
7
8
9
10
11
12

Watching forfilechanges with StatReloader

Performing system checks…

System check identified no issues(silenced).

You have17unapplied migration(s).Your project may notwork properly untilyou apply the migrations forapp(s)admin,auth,contenttypes,sessions.

Run’python manage.py migrate’toapply them.

May05,2020-123609

Django version3.0,using settings’test_project.settings’

Starting development server athttp127.0.0.18000

Quit the server with CONTROL-C.

При посещении откроется следующая страница:

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

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

Shell

(django) $ exit

1 (django)$exit

Вновь активировать виртуальное окружение можно в любое время. — для этого используется команда в терминале.

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

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

Конвертеры маршрутов в Django 2.0+ (path converters)

Всем привет!
Маршрутизация в Django со второй версии фреймворка получила замечательный инструмент — конвертеры. С добавлением этого инструмента появилась возможность не только гибко настраивать параметры в маршрутах, но и разделять зоны ответственности компонентов.
Меня зовут Александр Иванов, я наставник в Яндекс.Практикуме на факультете бэкенд-разработки и ведущий разработчик в Лаборатории компьютерного моделирования. В этой статье я расскажу о конвертерах маршрутов в Django и покажу преимущества их использования.
Первое, с чего начну, — границы применимости:

  1. версия Django 2.0+;
  2. регистрация маршрутов должна выполняться с помощью .

Итак, когда к Django-серверу прилетает запрос, он сперва проходит через цепочку middleware, а затем в работу включается URLResolver (). Задача последнего — найти в списке зарегистрированных маршрутов подходящий.
Для предметного разбора предлагаю рассмотреть следующую ситуацию: есть несколько эндпоинтов, которые должны формировать разные отчёты за определённую дату. Предположим, что эндпоинты выглядят так:

3.5. Определяем URL’ы

использование функции не является строго обязательным, но я предпочитаю использовать ее: когда вы начнете добавлять больше информации в URL-шаблоны, она позволит вам использовать именованные параметры, делая код более чистым;
первый параметр принимаемый функцией — это регулярное выражение

Обратите внимание на замыкающий символ ; как думаете, почему он важен?
вторым параметром указывается вызываемое представление. Это может быть как непосредственно вызываемый объект (импортированный вручную), так и строка описывающая его

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

переменных

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock
detector