django.urls функции для использования в URLconfs¶
re_path() ¶
include() ¶
Обычно пространство имен приложения должно быть задано включенным модулем. Если пространство имен приложения задано, аргумент namespace может быть использован для задания другого пространства имен экземпляра.
include() также принимает в качестве аргумента либо итерабель, возвращающий шаблоны URL, либо кортеж, содержащий такую итерабель плюс имена пространств имен приложений.
register_converter() ¶
Функция для регистрации конвертера для использования в path() route s.
django.conf.urls функции для использования в URLconfs¶
static() ¶
Вспомогательная функция для возврата шаблона URL для обслуживания файлов в режиме отладки:
Не рекомендуется, начиная с версии 3.1: Псевдоним django.urls.re_path() для обратной совместимости.
handler400 ¶
Вызываемый объект, или строка, представляющая полный путь импорта Python к представлению, которое должно быть вызвано, если HTTP-клиент отправил запрос, вызвавший состояние ошибки и ответ с кодом состояния 400.
handler403 ¶
Вызываемый объект, или строка, представляющая полный путь импорта Python к представлению, которое должно быть вызвано, если у пользователя нет необходимых разрешений для доступа к ресурсу.
handler404 ¶
Вызываемый объект или строка, представляющая полный путь импорта Python к представлению, которое должно быть вызвано, если ни один из шаблонов URL не совпадает.
handler500 ¶
Вызываемый объект, или строка, представляющая полный путь импорта Python к представлению, которое должно быть вызвано в случае ошибок сервера. Ошибки сервера возникают, когда в коде представления есть ошибки времени выполнения.
Django urls path параметры
Функции-представления могут принимать параметры, через которые могут передаваться различные данные. Подобный параметры передаются в в адресе URL. Например, в запросе http://localhost/index/3/5/ поледние два сегмента 3/5/ могут представлять параметры URL, которые могут быть связанны с параметрами функции-представления через систему маршрутизации.
Определение параметров через функцию re_path
Определим в приложении в файле views.py следующие функции:
Во втором шаблоне адреса определяются два параметра: id и name ( (?P \d+)/(?P \D+) ). При этом параметр id должен представлять число, а параметр name должен состоять только из буквенных символов.
Ну и также отметим, что количество и название параметров в шаблонах адресов URL соответствуют количеству и названиям параметров соответствующих функций, которые обрабатывают запросы по данным адресам.
Теперь мы можем чем адресную строку передать данные в приложение:
Однако, что если мы не передадим значение для параметра или передадим ему значение, которое не соответствует регулярному выражению? В этом случае система не смодет найти ресурс для обработки запроса:
В этом случае мы можем определить в файле views.py для параметра функции products значение параметра по умолчанию:
То есть если в функцию не передается значение для параметра productid, то он получает значение 21.
В этом случае надо дополнительно определить еще один маршрут в файле urls.py :
Определение параметров через функцию path
Возьмем те же функции в файле views.py :
Определение параметров с помощью функции path() будет выглядеть следующим образом:
По умолчанию Django предоставляет следующие спецификаторы:
str : соответствует любой строке за исключенем символа «/». Если спецификатор не указан, то используется по умолчанию
int : соответствует любому положительному числу
slug : соответствует последовательности буквенных символов ASCII, цифр, дефиса и символа подчеркивания, например, building-your-1st-django-site
uuid : сооветствует идентификатору UUID, например, 075194d3-6885-417e-a8a8-6c931e272f00
path : соответствует любой строке, которая также может включать символ «/» в отличие от спецификатора str
Значения для параметров по умолчанию
Определеним для функций в views.py значения для параметров по умолчанию:
В этом случае для каждой функции надо определить по два маршрута:
Django urls path параметры
В прошлой теме рассматривалось сопоставление адресов URL и функций, которые обрабатывают запросы по этим адресам. Например, у нас есть следующие функции в файле views.py :
И в файле urls.py они сопоставляются с адресами URL с помощью функции path() :
Функция path() располагается в пакете django.urls и принимает два параметра: запрошенный адрес URL и функция, которая обрабатывает запрос по этому адресу. Дополнительно через третий параметр можно указать имя маршрута:
В данном случае маршрут будет называться «home».
Однако функция path ограничена по своему действию. Запрошенный путь должен в точности соответствовать указанному в маршруте адресу URL. Так, в примере выше, что функция views.about могла обрабатывать запрос, адрес должен быть в точности «about». Например, стоит нам указать слеш в конце: «about/» и django уже не сможет сопоставить путь с запросом.
re_path
Например, изменим определение файла urls.py следующим образом:
Адрес в первом маршруте по-прежнему образуется с помощью функции path и указывает на корень веб-приложения.
Например, мы можем обратиться по любому адресу, главное чтобы он начинался с «about», и тогда подобный запрос будет обрабатываться функцией views.about.
Очередность маршрутов
Когда запрос приходит к приложению, то система проверяет соответствие запроса маршрутам по мере их определения: вначале сравнивается первый маршрут, если он не подходит, то сравнивается второй и так далее. Поэтому более общие маршруты должны определяться в последнюю очередь, а более конкретные маршруты должны идти в начале. Например:
В данном случае адрес «^about/contact» представляет более конкретный маршрут по сравнению c «^about». Поэтому он определяется в первую очередь.
Основные элементы синтаксиса регуляных выражений
Некоторые базовые элементы регуляных выражений, которые можно использовать для определения адресов URL:
Документация Django 3.0
Чистая, элегантная схема URL-ов – это важная часть качественного приложения. Django позволяет проектировать URL-адреса как вы пожелаете, без ограничений «фреймворка».
Читайте Cool URIs don’t change, создателя World Wide Web, Тима Бернерса-Ли, чтобы узнать почему URL-ы должны быть красивыми и практичными.
Обзор¶
To design URLs for an app, you create a Python module informally called a URLconf (URL configuration). This module is pure Python code and is a mapping between URL path expressions to Python functions (your views).
Эта конфигурация может быть короткой или длинной настолько, насколько это нужно. Она может ссылаться на другие конфигурации. И, так как это код Python, может создаваться динамически.
Django также предоставляет метод для перевода URL на текущий язык. Обратитесь к документации на интернационализацию для подробностей.
Как Django обрабатывает запрос¶
При запросе к странице вашего Django-сайта, используется такой алгоритм для определения какой код выполнить:
Django determines the root URLconf module to use. Ordinarily, this is the value of the ROOT_URLCONF setting, but if the incoming HttpRequest object has a urlconf attribute (set by middleware), its value will be used in place of the ROOT_URLCONF setting.
Once one of the URL patterns matches, Django imports and calls the given view, which is a Python function (or a class-based view ). The view gets passed the following arguments:
If the matched URL pattern contained no named groups, then the matches from the regular expression are provided as positional arguments.
In older versions, the keyword arguments with None values are made up also for not provided named parts.
If no URL pattern matches, or if an exception is raised during any point in this process, Django invokes an appropriate error-handling view. See Error handling below.
Например¶
Вот пример простого URLconf:
Path converters¶
The following path converters are available by default:
Registering custom path converters¶
For more complex matching requirements, you can define your own path converters.
A converter is a class that includes the following:
Register custom converter classes in your URLconf using register_converter() :
Using regular expressions¶
Here’s the example URLconf from earlier, rewritten using regular expressions:
This accomplishes roughly the same thing as the previous example, except:
When switching from using path() to re_path() or vice versa, it’s particularly important to be aware that the type of the view arguments may change, and so you may need to adapt your views.
Using unnamed regular expression groups¶
This usage isn’t particularly recommended as it makes it easier to accidentally introduce errors between the intended meaning of a match and the arguments of the view.
In either case, using only one style within a given regex is recommended. When both styles are mixed, any unnamed groups are ignored and only named groups are passed to the view function.
Вложенные аргументы¶
Регулярные выражения позволяют использовать вложенные аргументы, и Django может их найти и передать в представление. Во время поиска аргументов Django попытается получить самый внешний аргумент, игнорируя вложенные аргументы. Возьмем следующие шаблоны URL-ов, которые принимает необязательный номер страницы:
При получении URL-а для представления blog_articles необходимо указать самый внешний аргумент( page-2/ ) или ни одного аргумента в данном случае. В то время как для comments необходимо передать значение page_number или не одного аргумента.
Вложенные захватываемые аргументы создают сильную связанность между URL и аргументами представления, как это показано для blog_articles : представление получает часть URL-а ( page-2/ ) вместо значение, которое на самом деле необходимо представлению. Эта связанность особенно заметна при создании URL-а т.к. необходимо передать часть URL-а вместо номера страницы.
Как правило, URL-шаблон должен захватывать только необходимые для представления аргументы.
Что использует URLconf при поиске нужного шаблона URL¶
URLconf использует запрашиваемый URL как обычную строку Python. Он не учитывает параметры GET, POST и имя домена.
Значения по умолчанию для аргументов представления¶
Принято указывать значения по-умолчанию для аргументов представления. Пример URLconf и представления:
Производительность¶
Каждое регулярное выражение в urlpatterns будет скомпилировано при первом использовании. Это делает систему невероятно быстрой.
Syntax of the urlpatterns variable¶
urlpatterns should be a sequence of path() and/or re_path() instances.
Обработчики ошибок¶
When Django can’t find a match for the requested URL, or when an exception is raised, Django invokes an error-handling view.
Эти представления определены в четырёх переменных. Их значения по-умолчанию должны подойти для большинства проектов, но вы можете их поменять при необходимости.
Эти значения должны быть определены в главном URLconf.
Значение это функции, или полный путь для импорта, которая будет вызвана, если не был найден подходящий URL-шаблон.
Есть следующие переменные:
Комбинирование URLconfs¶
В любой момент, ваш urlpatterns может «включать» другие модули URLconf.
Вот пример URLconf для сайта Django. Он включает множество других конфигураций URL:
Another possibility is to include additional URL patterns by using a list of path() instances. For example, consider this URLconf:
Такой подход может применяться для уменьшения дублирования кода в настройках URL, когда используется один и тот же шаблонный префикс. Например, возьмём такую конфигурацию URL:
Мы можем сделать её проще, указав общий префикс только один раз и сгруппировав различающиеся суффиксы:
Нахождение аргументов в URL¶
Включенный URLconf получает все аргументы найденные родительским URLconfs, поэтому этот пример работает:
В примере выше, найденный аргумент «username» передается во включенный URLconf, как и ожидалось.
Передача дополнительных аргументов в представление¶
Конфигурация URL-ов позволяет определить дополнительные аргументы для функции представления, используя словарь Python.
The path() function can take an optional third argument which should be a dictionary of extra keyword arguments to pass to the view function.
Такой подход используется в syndication framework для передачи параметров и дополнительных данных в представление.
Если регулярное выражение URL-шаблона выделяет из URL-а аргумент с названием, которое уже используется в дополнительных именованных аргументах, будет использован аргумент из словаря дополнительных аргументов, вместо значения из URL.
Передача дополнительных аргументов в include() ¶
Similarly, you can pass extra options to include() and each line in the included URLconf will be passed the extra options.
Например, эти два URLconf работают идентично:
Дополнительные аргументы всегда передаются каждому представлению во включенном URLconf, независимо от того, принимает оно эти аргументы или нет. Поэтому, такой подход полезен только если вы уверенны, что каждое представление принимает передаваемые аргументы.
Поиск URL-а по URL-шаблону¶
Обычной задачей является получение URL-а по его определению для отображения пользователю или для редиректа.
Очень важно не «хардкодить» URL-ы (трудоемкая и плохо поддерживаемая стратегия). Также не следует создавать «костыли» для генерации URL-ов, которые не следуют задокументированному дизайну URLconf.
В общем необходимо придерживаться принципа DRY. Немаловажно иметь возможность менять URL-ы в одном месте, а не выполнять поиск и замену по всему проекту.
Для получения URL-а нам необходим его идентификатор, то есть название URL-шаблона, и позиционные и именованные аргументы.
В Django для работы с URL-ами используется так называемый «URL mapper». Ему передается URLconf, и теперь его можно использовать в два направления:
Первое это то, что мы уже рассмотрели в предыдущем разделе. Второе называется URL reversing, в общем получение URL-а по его названию.
Django предоставляет инструменты для получения URL-ов в различных компонентах фреймворка:
Примеры¶
Рассмотрим следующий URLconf:
Вы можете получить его в шаблоне следующим образом:
Если по каким-либо причинам необходимо будет изменить URL, достаточно будет изменить запись в вашем URLconf.
В некоторых случаях URL-ы и представления могут соотноситься как многое-к-одному. В таких случаях название представления не может идентифицировать конкретный URL. Как решить эту проблему читайте в следующем разделе.
Именованные URL-шаблоны¶
Для того, чтобы выполнить обратное разрешение URL, вам потребуется использовать именованные URL шаблоны, как это показано в примерах выше. Строка, использованная для наименования URL, может содержать любые символы. Вы не ограничены только теми именами, что позволяет Python.
When naming URL patterns, choose names that are unlikely to clash with other applications“ choice of names. If you call your URL pattern comment and another application does the same thing, the URL that reverse() finds depends on whichever pattern is last in your project’s urlpatterns list.
Putting a prefix on your URL names, perhaps derived from the application name (such as myapp-comment instead of comment ), decreases the chance of collision.
You may also use the same name for multiple URL patterns if they differ in their arguments. In addition to the URL name, reverse() matches the number of arguments and the names of the keyword arguments.
Пространства имен в конфигурации URL-ов¶
Описание¶
Пространства имен позволяют получить URL по названию URL-шаблона даже, если несколько приложений используют одинаковые названия. Для сторонних приложений использование пространств имен – хорошая практика (как мы и делали в учебнике). Аналогично можно получить URL, если несколько экземпляров одного приложения подключены в конфигурацию URL-ов.
Пространство имен состоит из двух частей, каждая из которых это строка:
Поиск URL-а по шаблону с пространством имен¶
Если необходимо найти URL по названию с пространством имен (например, ‘polls:index’ ), Django разбивает название на части и следует такому алгоритму:
Первым делом, Django проверяет название(пространсву имен) приложения (например, polls ). Django получает список экземпляров приложения.
If there is a current application defined, Django finds and returns the URL resolver for that instance. The current application can be specified with the current_app argument to the reverse() function.
If there is no current application, Django looks for a default application instance. The default application instance is the instance that has an instance namespace matching the application namespace (in this example, an instance of polls called ‘polls’ ).
Если экземпляр по-умолчанию не найден, Django возьмет последний установленный экземпляр приложения, не обращая внимание на его название.
Если на первом шаге не было найдено приложение по указанному пространству имен, Django попытается найти экземпляр приложения по его названию, используя пространство имен как название экземпляра.
Если пространство имен вложенное, этот процесс будет повторен, пока неопределенным не останется только название представления. URL для названия представления будет искаться среди URL-шаблонов определенных в приложении, найденном через пространство имен.
Например¶
Формирование URL-адресов в шаблонах
На данный момент мы с вами научились создавать шаблоны, прописывать в них различные теги <% имя_тега %>, переменные << имя_переменной >> и фильтры <
Следующий важный шаг – научиться правильно указывать URL-адреса в наших шаблонах. На предыдущих занятиях почти у всех ссылок я ставил заглушки – символ шарп:
Пришло время сформировать полноценные ссылки на страницы. Для этого в Django используется специальный тег:
Давайте для начала пропишем с помощью этого тега маршрут к главной странице в шаблоне base.html. В нем имеется вот такая строчка:
Здесь косая черта – это как раз ссылка на главную страницу. Но это не лучший подход, так как URL-адрес главной не обязательно должен совпадать с доменным именем (в нашем случае: http://127.0.0.1:8000/). Мы можем определить ее и как-то иначе, например:
И тогда везде в шаблонах придется вносить эти изменения. Гораздо практичнее и, чаще всего, так и делают, используют имена маршрутов. Если мы откроем файл women/urls.py, то увидим, что главная страница имеет имя home. Им мы и воспользуемся, указав в теге url:
Видите, как это удобно. Теперь, если изменить адрес главной страницы:
И перейти по адресу:
то ссылка на главную автоматически изменится. В этом удобство именованных ссылок.
Но вернем прежний адрес главной страницы, так будет удобнее. Добавим ссылки для нашего главного меню. Вначале переопределим список menu, указав не только заголовок, но и имя ссылки:
Затем, в файле women/urls.py сформируем маршруты к этим страницам:
И в файле women/views.py пропишем указанные функции представлений:
Пока это просто функции-заглушки. А вот функцию index перепишем в таком виде:
Смотрите, мы здесь определили отдельный словарь context, в котором указали все те параметры, что собираемся передавать шаблону index.html, а затем, в функции render передаем этот словарь с помощью именованного параметра context. Это будет эквивалентно предыдущей записи, но так текст программы читается гораздо лучше.
Осталось в самом шаблоне правильно обработать коллекцию menu. В файле шаблона base.html пропишем следующие строчки:
Теперь, при обновлении страницы мы получаем полноценные ссылки в главном меню.
Формирование динамических URL-адресов
Осталось прописать ссылки у списка наших статей. Во-первых, определим шаблон маршрута, по которому они будут доступны. Для этого в файле women/urls.py добавим строчку в urlpatterns:
то есть, маршрут постов будет выглядеть так:
Конечно, в реальных проектах вместо post_id, как правило, используется строка (слаг), записанная латиницей и отражающая суть статьи. Такие ссылки лучше ранжируются поисковыми системами и понятнее пользователям сайта. Позже мы тоже будем использовать слаг, но на данном этапе нам важно разобраться, как создавать динамические URL-ссылки на уровне шаблонов.
Итак, маршрут определен, имя маршрута задано как post, осталось прописать функцию представления show_post. Мы ее пока определим вот такой заглушкой:
Осталось все это определить в шаблоне index.html, в котором происходит отображение списка статей. Фактически, все что нам нужно – это переписать следующую строчку:
Смотрите, здесь в параметре href используется уже знакомый нам тег шаблона url, далее указываем имя ссылки post и через пробел ее параметр post_id в виде p.pk. Вспоминаем, что мы перебираем здесь коллекцию posts, которая хранит ссылки на объекты класса модели Women. И у этих объектов имеется параметр pk, равный идентификатору записи. Почему мы используем pk, а не id? В принципе, можно указать е его, но согласно конвенции Django, лучше использовать атрибут pk.
Если теперь обновим главную страницу, то у всех постов появятся сформированные нами ссылки и каждая будет соответствовать своей статье. Щелкая по любой из них, перейдем по адресу, например:
и увидим строчку «Отображение статьи с от функции заглушки show_post. Вот так довольно просто можно формировать различные динамические URL-адреса на уровне шаблонов.
Функция get_absolute_url()
Как я уже не раз отмечал, фреймворк Django работает согласно паттерну MTV (Models, Templates, Views), то есть, ему постоянно приходится связывать модели с шаблонами и видами, а значит, формировать URL-ссылки для выбранных записей из таблиц БД. И мы только что это делали – формировали URL-ссылки для записей модели Women. При разработке сайтов – это типовая операция. Поэтому, разработчики Django озаботились упрощением и автоматизацией этой процедуры. Что они нам предлагают? Смотрите. В классах моделей можно определять специальный метод под названием:
который бы возвращал полный URL-адрес для каждой конкретной записи (ассоциированной с текущим объектом). Например, в классе модели Women мы можем определить этот метод следующим образом:
Здесь используется функция reverse, которая строит текущий URL-адрес записи на основе имени маршрута post и словаря параметров kwargs. В данном случае указан один параметр post_id со значением идентификатора объекта self.pk. Разумеется, вначале нам нужно импортировать эту функцию:
Все, теперь при обращении к методу get_absolute_url объекта класса модели Women, мы будем получать ее URL-адрес.
Где здесь упрощение и автоматизация? Смотрите, в шаблоне index.html, при формировании ссылок статей, мы теперь можем вместо тега шаблона url указать метод get_absolute_url:
Вспоминаем, что p как раз ссылается на объекты класса Women, следовательно, у нее появился атрибут get_absolute_url, который мы и прописываем. И, обратите внимание, при указании этого метода, мы не пишем в конце круглые скобки, т.к. он здесь самостоятельно не вызывается. Вызов сделает функция render при обработке этого шаблона.
Почему это лучше тега url? Представьте, что в будущем мы изменили шаблон этой ссылки и стали выводить посты не по id, а по слагу. Тогда, при использовании тега url, нам пришлось бы менять эти ссылки в каждом шаблоне, заменяя self.pk на self.slug, например. В этом как раз неудобство и источник потенциальных ошибок. Теперь, с методом get_absolute_url() нам достаточно изменить маршрут в нем и это автоматически скажется на всех шаблонах, где она используется.
Второй важный момент функции get_absolute_url() заключается в том, что согласно конвенции, модули Django используют этот метод в своей работе (если он определен в модели). Например, стандартная админ-панель обращается к этому методу для построения ссылок на каждую запись наших моделей. И в дальнейшем мы увидим как это работает.
В свою очередь тег <% url %>имеет смысл применять для построения ссылок не связанных с моделями или, для ссылок без параметров, используя только имена маршрутов.
Видео по теме
#2. Модель MTV. Маршрутизация. Функции представления
#3. Маршрутизация, обработка исключений запросов, перенаправления
#4. Определение моделей. Миграции: создание и выполнение
#6. Шаблоны (templates). Начало
#7. Подключение статических файлов. Фильтры шаблонов
#8. Формирование URL-адресов в шаблонах
#9. Создание связей между моделями через класс ForeignKey
#10. Начинаем работу с админ-панелью
#11. Пользовательские теги шаблонов
#12. Добавляем слаги (slug) к URL-адресам
#13. Использование форм, не связанных с моделями
#14. Формы, связанные с моделями. Пользовательские валидаторы
#15. Классы представлений: ListView, DetailView, CreateView
#16. Основы ORM Django за час
#18. Постраничная навигация (пагинация)
#19. Регистрация пользователей на сайте
#20. Делаем авторизацию пользователей на сайте
#21. Оптимизация сайта с Django Debug Toolbar
#22. Включаем кэширование данных
#23. Использование капчи captcha
#24. Тонкая настройка админ панели
#25. Начинаем развертывание Django-сайта на хостинге
#26. Завершаем развертывание Django-сайта на хостинге
© 2021 Частичное или полное копирование информации с данного сайта для распространения на других ресурсах, в том числе и бумажных, строго запрещено. Все тексты и изображения являются собственностью сайта