В прошлой теме рассматривалось сопоставление адресов URL и функций, которые обрабатывают запросы по этим адресам. Например, у нас есть следующие функции в файле views.py :
И в файле urls.py они сопоставляются с адресами URL с помощью функции path() :
Функция path() располагается в пакете django.urls и принимает два параметра: запрошенный адрес URL и функция, которая обрабатывает запрос по этому адресу. Дополнительно через третий параметр можно указать имя маршрута:
В данном случае маршрут будет называться «home».
Однако функция path ограничена по своему действию. Запрошенный путь должен в точности соответствовать указанному в маршруте адресу URL. Так, в примере выше, что функция views.about могла обрабатывать запрос, адрес должен быть в точности «about». Например, стоит нам указать слеш в конце: «about/» и django уже не сможет сопоставить путь с запросом.
re_path
В качестве альтернативы для определения маршрутов мы можем использовать функцию re_path() , которая также располагается в пакете django.urls. Ее преимущесто состоит в том, что она позволяет задать адреса URL с помощью регулярных выражений.
Например, изменим определение файла urls.py следующим образом:
Адрес в первом маршруте по-прежнему образуется с помощью функции path и указывает на корень веб-приложения.
Остальные два маршрута образуются с помощью функции re_path() . Причем, поскольку определяется регуляное выражение, то перед строкой с шаблоном адреса URL ставится буква r . В самом шаблоне адреса можно использовать различные элементы синтаксиса регулярных выражений. В частности, выражение ^about указывает, что адрес должен начинаться с «about». Однако он необязательно в точности должен соответствовать строке «about», как это было в случае с функцией path.
Например, мы можем обратиться по любому адресу, главное чтобы он начинался с «about», и тогда подобный запрос будет обрабатываться функцией views.about.
Очередность маршрутов
Когда запрос приходит к приложению, то система проверяет соответствие запроса маршрутам по мере их определения: вначале сравнивается первый маршрут, если он не подходит, то сравнивается второй и так далее. Поэтому более общие маршруты должны определяться в последнюю очередь, а более конкретные маршруты должны идти в начале. Например:
В данном случае адрес «^about/contact» представляет более конкретный маршрут по сравнению c «^about». Поэтому он определяется в первую очередь.
Основные элементы синтаксиса регуляных выражений
Некоторые базовые элементы регуляных выражений, которые можно использовать для определения адресов URL:
Подскажите как добавить в url слово, чтобы оно не шло в параметр есть такая строчка
она формирует такого типа адрес ski/switzerland/verbier.html
нужно сдалать чтобы на другую view переходили по такому url ski/switzerland/verbier_options.html
вот эта строчка выкидывает на туже вьюху resorts.views.resort_detail_description
UPD полный код urls.py
то что закоментированно, это те url которые раньше были, то есть раньше на странице выдавалась инфа сразу вся, а теперь надо по url’ам разделить.
UPD2 По совету Ilya Pirogov поменял маршруты местами и заработало. Теперь вопрос, а почему?
И вопрос все-равно остался, а как в urls исключить какую-то фразу, чтобы она не попадала в параметр?
Мы собираемся сделать нашу первую веб-страничку — домашнюю страницу твоего блога! Но для начала давай чуть ближе познакомимся с URL-адресами в Django.
Что такое URL-адрес?
URL — это просто адрес в интернете. Ты можешь увидеть URL каждый раз, когда посещаешь веб-сайт — он отображается в адресной строке твоего браузера (да, 127.0.0.1:8000 — это URL-адрес! И https://djangogirls.org — тоже URL):
Любая страница в Интернете нуждается в собственном URL-адресе. Таким образом ваше приложение точно знает, что показать пользователю, который открывает конкретный URL-адрес. В Django мы используем так называемый URLconf (англ. URL configuration, конфигурация URL). URLconf — это набор шаблонов, которые Django попробует сравнить с полученным URL, чтобы выбрать правильный метод для отображения (view).
Как URL-адреса работают в Django?
Давай откроем файл mysite/urls.py в нашем редакторе и посмотрим, как он выглядит:
Как можешь заметить, Django уже кое-что разместил здесь для нас.
Строки, расположенные между тройными кавычками ( »’ или «»» ), называются docstrings — ты можешь добавить их в начале файла, класса или метода для описания их функциональности. Python будет их игнорировать при запуске приложения.
URL-адрес раздела администрирования, который мы посещали в предыдущей главе, уже здесь присутствует:
Таким образом, любому URL-адресу, начинающемуся с admin/ , Django будет находить соответствующее view (представление). В этом случае мы охватываем большое количество различных URL-адресов, которые явно не прописаны в этом маленьком файле — так он становится более аккуратным и удобочитаемым.
Твой первый URL-адрес в Django!
Пришло время создать твой первый URL-адрес! Мы хотим, чтобы ‘http://127.0.0.1:8000/’ возвращал домашнюю страничку нашего блога со списком записей в нём.
Мы также хотим сохранить файл mysite/urls.py в максимально аккуратном виде, так что мы импортируем URL-адреса для нашего приложения blog в mysite/urls.py .
Вперёд, добавь строку для импорта blog.urls . Обрати внимание, что здесь мы используем функцию include , поэтому тебе придется импортировать её в строке from django.urls. .
Файл mysite/urls.py должен выглядеть следующим образом:
Django теперь будет перенаправлять все запросы ‘http://127.0.0.1:8000/’ к blog.urls и искать там дальнейшие инструкции.
blog.urls
Создай новый пустой файл blog/urls.py . Отлично! Добавь в него следующие две строки:
Так мы импортировали функцию path Django и все views (представления) из приложения blog (у нас их пока нет, но через минуту они появятся!)
После этого мы можем добавить наш первый URL-шаблон:
Как ты можешь заметить, мы связали view под именем post_list с корневым URL-адресом ( » ). Этот шаблон URL будет соответствовать пустой строке. Это правильно, потому что для обработчиков URL в Django ‘http://127.0.0.1:8000/’ не является частью URL. Этот шаблон скажет Django, что views.post_list — это правильное направление для запроса к твоему веб-сайту по адресу ‘http://127.0.0.1:8000/’.
Последняя часть name=’post_list’ — это имя URL, которое будет использовано, чтобы идентифицировать его. Оно может быть таким же, как имя представления (англ. view), а может и чем-то совершенно другим. Мы будем использовать именованные URL позднее в проекте, поэтому важно указывать их имена уже сейчас. Мы также должны попытаться сохранить имена URL-адресов уникальными и легко запоминающимися.
Если сейчас ты попытаешься открыть страницу в браузере, то увидишь сообщение о том, что веб-страница недоступна. Это произошло потому, что сервер (помнишь, как мы набирали runserver ?) перестал обрабатывать запросы. Чтобы понять почему, открой окно своей командной строки.
В твоей командной строке появилось сообщение об ошибке, но не беспокойся — оно, на самом деле, довольно полезно. Ты можешь прочесть, что не существует атрибута с именем ‘postlist’ — _no attribute ‘post_list’. Это название представления, которое Django пытается найти и использовать, но мы же его ещё не создали. В данный момент раздел /admin/ тоже не будет работать. Не беспокойся, мы этим займёмся.