Импортируйте файл icecream views py в icecream urls py иначе вообще ничего не заработает
Обновлено: 06.07.2024
Я строю проект в Django Rest Framework, где пользователи могут войти в систему, чтобы просмотреть свой винный погреб. Мои ModelViewSets работали просто отлично, и внезапно я получаю эту неприятную ошибку:
не удалось разрешить URL для гиперссылок, используя имя представления "user-detail". Возможно, Вам не удалось включить связанную модель в API или неправильно настроили lookup_field атрибут в этом поле.
у меня есть пользовательская модель пользователя электронной почты и модель бутылки в models.py есть:
у меня нет подробного представления пользователя, и я не вижу, откуда может возникнуть эта проблема. Есть идеи?
потому что это HyperlinkedModelSerializer ваш сериализатор пытается разрешить URL-адрес для соответствующего User на Bottle .
Поскольку у вас нет подробного представления пользователя, он не может этого сделать. Отсюда и исключение.
- будет не просто регистрация UserViewSet с маршрутизатором решить вашу проблему?
- вы можете определить поле пользователя на вашем BottleSerializer чтобы явно использовать UserSerializer вместо того чтобы пытаться разрешить URL-адрес. Вижу сериализатор документов по работе с вложенные объекты для этого.
я тоже наткнулся на эту ошибку и решил ее следующим образом:
причина в том, что я забыл дать "**-detail" (view_name, например: user-detail) пространство имен. Таким образом, Django Rest Framework не смог найти это представление.
в моем проекте есть одно приложение, предположим, что мое имя проекта myproject и имя приложения myapp .
есть два urls.py файл, один myproject/urls.py и другое myapp/urls.py . Я даю приложению пространство имен в myproject/urls.py , просто например:
Я зарегистрировал маршрутизаторы Rest framework в myapp/urls.py , а затем получил эту ошибку.
мое решение состояло в том, чтобы предоставить url-адрес с пространством имен явно:
и это решило мою проблему.
при использовании пространства имен с гиперссылками сериализаторов вам также необходимо убедиться, что любые параметры view_name сериализаторов правильно отражают пространство имен. Например:
вам нужно включить такой параметр, как view_name='api:user-detail' для полей сериализатора, гиперссылка на представление сведений о пользователе.
этот код тоже должен работать.
еще одна неприятная ошибка, которая вызывает эту ошибку, имеет имя base_name, излишне определенное в вашем urls.py - . Например:
это вызовет ошибку, указанную выше. Получите это имя base_name оттуда и вернитесь к рабочему API. Приведенный ниже код исправит ошибку. Ура!
мой ModelViewSet (пользовательские get_queryset поэтому мне пришлось добавить base_name к маршрутизатору.регистрация() в первую очередь):
моя регистрация маршрутизатора для этого ModelViewSet в urls.py:
И ВОТ ГДЕ ДЕНЬГИ! Тогда я мог бы решить это так:
да. Вы должны явно определить это HyperlinkedIdentityField на себе, чтобы он работал. И тебе нужно сделать конечно, что view_name определенный на HyperlinkedIdentityField такой же, как вы определили на base_name in urls.py с добавлением "- детали " после него.
та же ошибка, но другая причина:
Я определяю пользовательскую модель пользователя, ничего нового поля:
это моя функция вида:
вам понадобится base_name то же, что и название вашей модели - customuser .
Если вы расширяете границы GenericViewSet и ListModelMixin классы и имеют ту же ошибку при добавлении URL-адресом поле в представлении списка, это потому, что вы не определяете подробное представление. Убедитесь, что вы расширяете RetrieveModelMixin миксин:
мое решение было не в коде, а в замене базы данных.
разница между этой установкой и другими ранее была, когда я создал локальную базу данных.
на этот раз я побежал мой
вместо точного порядка, указанного в руководстве.
Я подозревал, что что-то не правильно создал в БД. Я не заботился о своей dev db, поэтому я удалил его и запустил ./manage.py migrate команда еще раз, создала супер пользователя, просмотрела /users и ошибка исчезла.
что-то было проблематично с порядком операций, в котором я настроил DRF и db.
Если вы используете sqlite и могут протестировать изменение на новую БД, то стоит попробовать, прежде чем вы идете препарировать весь свой код.
бутылка = сериализатор.PrimaryKeyRelatedField (read_only=True)
read_only позволяет представлять поле без необходимости связывать его с другим представлением модели.
Я получил эту ошибку на DRF 3.7.7, когда значение slug было пустым (равно ") в базе данных.
я столкнулся с этой же проблемой и решил ее, добавив generics.RetrieveAPIView как базовый класс для моего набора представлений.
Я застрял в этой ошибке почти на 2 часа:
ImproperlyConfigured at /api_users / пользователи/1/ Не удалось разрешить URL-адрес для гиперссылок, используя имя представления "пользователи-подробности". Возможно, Вам не удалось включить связанную модель в API или неправильно настроили lookup_field атрибут в этом поле.
когда я наконец получаю решение, но я не понимаю, почему, поэтому мой код:
но в моих основных URL-адресах это было:
Итак, наконец, я решаю проблему стирания пространства имен:
и я, наконец, решаю свою проблему, так что любой может дать мне знать, почему, bests.
Django — это очень интересный фреймворк, который позволяет создавать веб-приложения с использованием Python для бэкенда. При этом он также может обрабатывать большинство функций базы данных и позволяет при работе по крайней мере с небольшими приложениями сосредотачиваться на основном, не отвлекаясь на сопутствующие процессы.
Несмотря на то, что Django очень эффективен, освоить его не столь просто, что может напугать начинающих.
В текущей статье я постараюсь упростить знакомство с этим инструментом и представлю некоторые из важнейших его возможностей и приемов.
1. Переиспользование кода шаблонов
В Django есть множество способов повторно использовать код, а также повышать его эффективность и читаемость. Один из таких — теги и фильтры шаблонов.
С их помощью можно писать логику внутри HTML-файла и отображать релевантные данные. Существует много встроенных тегов и фильтров, но можно создавать и свои.
Один из таких тегов, include , позволяет переиспользовать HTML-код. Вот, как я применил его на своем сайте:
Я хотел отображать последние статьи на странице “Home”, а также на странице “Articles”.
Поскольку дизайн карточки статьи остается таким же, то проще всего создать общий HTML и использовать его повторно на обеих страницах с помощью include . В коде это выглядит так:
Перед вами фрагмент кода из index.html , реализующий отображение статей. Данные для них получаются из файла views.py .
Как видите, в этом фрагменте перебираются все статьи, предоставляемые файлом views.py , и для каждой из них создается , добавляющий нужный HTML. (В следующем примере мы посмотрим, как файл views.py передает эти данные). Синтаксис использования include выглядит так:
Ключевое слово with является необязательным и используется при необходимости передачи в HTML аргументов. Для передачи строковых аргументов их нужно заключать в "" . При этом также можно передавать переменные.
article.html — общий HTML-файл для всех карточек статей:
Код выше предназначен для карточки статьи. В первой строке с помощью происходит обращение к статическим файлам, т.е. ко всем CSS, JS и изображениям. Чтобы использовать теги, передаваемые из тега include , необходимо поместить имя аргумента в > подобным образом: > .
Мы разобрали переиспользование HTML. Теперь рассмотрим представления, основанные на классах, которыми зачастую пренебрегают.
2. Представления на основе функций
Для начала хочу прояснить заблуждение относительно того, что представления на базе классов (CBV) лучше представлений на базе функций (FBV).
Все зависит от конкретного случая, и у обоих этих способов есть свои недостатки. Я добавил в статью CBV, потому что они позволяют удалять лишние элементы кода, которые зачастую присутствуют при использовании FBV. Так что знать о CBV желательно.
Если вы уже реализовывали какой-либо проект Django, то с FBV должны быть знакомы. Их удобно создавать и читать, но не так удобно переиспользовать.
Django предлагает общие варианты представлений, которые можно наследовать в собственный класс, переопределив их содержимое. Получается, что большая часть всего уже создана, и нужно лишь настроить представления согласно собственным нуждам. Вот как я делал это в своем блоге.
Фрагмент файла views.py :
ListView является одним из наиболее распространенных общих классов, которые я использовал для перечисления всех элементов базы данных. Для его применения нужно просто создать класс в файле views.py и наследовать его из django.views.generic import ListView .
В самом простом случае потребуется лишь создать переменную model , а Django разберется с остальным. По умолчанию шаблон имеет имя "model_name"_list.html , которое можно изменить, как сделал я выше.
Дальнейшая настройка предполагает переопределение функций. В моем случае нужно было отсортировать статьи по дате или тегам, после чего разделить их на три части для трех столбцов в файле шаблона. Ниже показано, как можно использовать articles_data в этом файле.
Фрагмент из articles.html :
В предыдущем примере показано, как повторно использовать шаблоны при помощи include . В этом случае шаблон получает данные из left , right и middle переменной articles_data . Но это не то, что нам нужно. Для использования CBV нужно кое-что проделать в файле urls.py .
Я подредактировал urls.py , чтобы упростить пример.
Сначала нужно импортировать класс, после чего использовать его в urlpatterns с помощью функции as_view() . Причина в том, что преобразователь URL ожидает отправки запроса и аргументов в функцию, а не класс. Поэтому нужно просто использовать функцию .as_view() , а остальное оставить Django.
3. Объемный файл views.py
Файл views.py содержит большую часть логики, в связи с чем может разрастаться до сотен строк. Это сильно усложняет отладку и чтение кода. Вот как можно разбить этот файл без осложнений.
Создаем каталог views , а внутри него файл _init_.py . Теперь можно разбить файл views.py и поместить его функции или классы в отдельные файлы.
В моем случае я использовал файл views_a.py для всех CBV и создал дополнительные файлы для каждой операции.
Если вы разделите функции и классы из исходного views.py по нескольким файлам, то импортируйте все содержимое этих файлов в _init_.py , как показано здесь:
В показанном выше случае мне нужно импортировать только views_a . Дело в том, что все мои объекты представлений, которые будут использоваться в файле urls.py , находятся во views_a .
Если же в вашем случае они окажутся разделенными по нескольким файлам, то потребуется импортировать каждый.
В завершении введите from .views import * , чтобы импортировать все объекты представлений.
Если вы используете print для отладки кода, в терминале может оказаться множество строк вывода, а вам придется выяснять, к какому участку кода принадлежит конкретный вывод.
Например, запустив приведенный ниже скрипт…
…мы получим следующее:
Какой из этих выводов является num1 , а какой num2 ? Что делать, если будет более 5 переменных? Попытка найти отвечающий за вывод исходный код может занять много времени.
Для облегчения поиска можно добавить текст в объявлении печати:
Вывод понимается легче, но он по-прежнему отнимает некоторое количество времени. Есть способ, который отвечает за вывод без дополнительного текста:
Вот в чем прелесть использования I cecream .
Что такое Icecream?
Это библиотека Python, которая делает отладку печати более читабельной с минимальным количеством кода и поддерживающаяся в Python 2, Python 3, PyPy2 и PyPy3.
Для ее установки используется следующая команда:
Попробуем напечатать вывод функции Python:
Используя ic , мы видим не только выходные данные, но и функцию с ее аргументами. Удобно! Цвет в терминале также будет таким же, как и показанный выше вывод.
Проверка выполнения
Определить где был выполнен код можно следующим образом:
С Icecream задача решается простым вызовом ic() без дополнительных параметров:
Становится понятно, что код в строке 5 из функции hello был выполнен, а код в строке 7 не работал.
Кастомный префикс
Если хотите вставить кастомный префикс в свой оператор печати, например, время выполнения кода, I cecream позволит сделать и это:
Теперь время выполнения кода автоматически отображается в выходных данных.
Получаем больше контекста
Помимо информации об отвечающем за вывод коде можно узнать, из какой строки и файла был он был выполнен. Чтобы это реализовать и узнать контекст, добавьте includeContext=True в ic.configureOutput() :
Первый вывод был выполнен функцией plus_five из файла icecream_example.py в строке 7.
Удаляем Icecream после завершения отладки
I cecream можно использовать не только для отладки, но и, например, для красивой печати:
Поскольку теперь можно различить отладочный и красивый вывод, становится проще искать и удалять все операторы ic после отладки:
После удаления всех отладочных следов код остается чистым.
Заключение
Поскольку обнаружение, локализация и устранение ошибок очень важны в разработке, необходимо стараться делать этот этап проще и понятнее. Мы изучили, как сделать вывод отладочной информации на экран более читабельным и информативным с помощью I cecream. Существует масса других вариантов: django-debug-toolbar , py-spy , line_profiler , memory_profiler и т. д. но описанный в статье легковеснее и практичнее.
Клиенту нужно угождать, ценить его время — так давайте попробуем облегчить процесс отправки электронного письма! Нам в этом поможет контактная форма, автоматически отправляющая письмо в техподдержку сайта. Хотя решение задачи на первый взгляд может показаться сложным, почти весь функционал успешно создается с помощью фреймворка Python Django.
Стат ь я даст ответы на следующие вопросы, волнующие каждого начинающего Python Django веб-разработчика.
- Как создать поля контактной формы Django?
- Как добавить форму в HTML шаблон?
- Как добавить бэкенд электронной почты Django?
Путь к файлу: env > mysite > main > forms.py
Внутри класса ContactForm(forms.Form) определите поля first_name и last_name (имя и фамилия), воспользовавшись классом CharField из модуля form — так создаются символьные (текстовые) поля. Для каждого из них установите атрибуту max_length значение 50: теперь форма ограничит допустимый ввод в одно поле до 50 символов. Затем добавьте новое поле email_address с помощью класса EmailField из модуля form — это специфическое поле, перед отправкой формы автоматически проверяющее соответствие ввода пользователя формату адреса электронной почты. Наконец, добавьте поле message с помощью того же класса CharField , но с виджетом forms.Textarea , указывающим, что данное поле будет отрисовываться в HTML как принимающее длинный текст в стиле абзаца.
Сохраните все изменения в файле forms.py !
Путь к файлу: env > mysite > main > views.py
Откройте файл views.py, импортируйте в него ряд объектов, которые нам пригодятся.
Путь к файлу: env > mysite > main > urls.py
Теперь добавим URL страницы с контактной формой в urls.py нашего приложения. Если же вы используете существующий шаблон с указанным ранее URL, то пропустите этот шаг.
Путь к файлу: env > mysite > main > templates > main > contact.html
Откройте файл contact.html или файл шаблона по вашему выбору и пропишите HTML-тег <form></form> под текстом. Добавьте к этому тегу атрибут method=”POST” , чтобы форма использовала метод POST при отправке данных обратно в функцию-представление contant(request) . Внутри элемента формы вложите шаблонный тег Django , чтобы предотвратить подделку формы злоумышленниками. Это очень важная строчка кода, которая позволит вашему Django-проекту безопасно отправлять информацию.
После CSRF-токена обратитесь к полям формы ContactForm , находящимся в контексте шаблона. Чтобы обернуть все поля в теги <p></p> , используйте > . Вы также можете получить доступ ко всем полям по отдельности, используя формат > .
Наконец, добавьте кнопку отправки формы непосредственно перед закрывающим тегом </form> .
Путь к файлу: env > mysite > main > settings.py
Если включен режим разработчика, то письмо отправляется в CLI (интерфейс командной строки), а не на почтовый ящик.
В нижней части файла settings.py добавьте вышеописанную константу EMAIL_BACKEND , так как именно она устанавливает командную строку/терминал в качестве почтового бэкенда Django для целей тестирования, но со временем стоит заменить настройку почтового бэкенда на реальный сервис отправки электронной почты.
macOS Terminal/Windows Command Prompt
Но как же узнать, что электронное письмо отправилось корректно?
Если бэкенд электронной почты Django в настройках не работает, то выполните следующие шаги.
Читайте также: