Почему Django не передает сообщения об ошибках с представлением по умолчанию 404? - PullRequest
2 голосов
/ 16 октября 2011

(Контекст: я все еще очень плохо знаком как с Django, так и с веб-разработкой.)

1) Может ли кто-нибудь объяснить причину следующего утверждения? Этот вопрос / ответ ответил на вопрос как справиться с этим, но не почему это может быть хорошая / плохая идея.

Документы заявляют, "представление page_not_found должно достаточно для 99% веб-приложений, но если вы хотите переопределить его, вы можете указать handler404 в вашем URLconf ".

То есть представление page_not_found передает только запрошенный URL и игнорирует любое сообщение, которое вы предоставляете при создании исключения. Мне кажется, что наличие опции для предоставления полезных советов шаблону 404.html по умолчанию будет хорошо для всех.

2) В настоящее время я делаю настраиваемое представление, чтобы я мог передавать полезные сообщения для следующей ситуации. Есть ли какая-то причина, по которой я не должен?

Я использую матричные URL, поэтому базовый ресурс обычный иерархический URL, за которым следуют параметры матрицы в основном формат: ; filter_type1 = item: value, item: value; filter_type2 = item: value ...

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

  • «Допустимые типы фильтра: type1, type2, type3.» или
  • «Допустимые элементы для filter_type a: item1, item2, item3.»

Извиняюсь, если я пропустил это объяснение в другом месте. Я посмотрел и я спросил в Google django-users , но не получил ответа.

Ответы [ 3 ]

1 голос
/ 17 октября 2011

Если ваши данные поступают как:

http://example.com/foo;bar;baz

Тогда вы делаете это неправильно :)

Затем вам нужно использовать регулярные выражения для анализа данных, которые должны быть обработаны,

Некоторые люди, сталкиваясь с проблемой, думают: «Я знаю, я буду использовать регулярные выражения».Теперь у них есть две проблемы.

(Zawinski, 1997)

Вместо этого, как предполагает пастилег, используйте параметры GET.

Еще лучше, используйте djangoобработка формы и:

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

Это можно сделать с помощью запросов GET или запросов POST.Преимущество POST заключается в наличии «чистых» URL и более длинном теле данных.GET означает, что URL-адреса могут быть добавлены в закладки.

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

1 голос
/ 25 февраля 2013

Я думаю, что причина, по которой у вас возникают проблемы с пониманием, заключается в том, что вы пытаетесь смешать 2 разных вопроса.

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

Итак, если (частично) url:

    .../whatever/?param1=value1&param2=value2

Если страница /whatever/default является не найдена , вам будет (должно быть) показано сообщение об ошибке типа "404 Page not found".В этом случае вы не можете сказать , были ли предоставленные параметры или значения правильными.Запрашиваемая страница не существует, поэтому вы не знаете, для какой страницы предназначались параметры.Вы даже не можете предположить, что был указан правильный domain name.Там может быть много произвольных доменов, URL-адресов и страниц, где параметры являются действительными, и многие другие, где параметры являются недействительными.

Если страница /whatever/default найдена , то:
Если указание неправильных параметров может привести к загрузке / перенаправлению этой страницы несуществующей страницы, то это должно быть предотвращеноэта страницаПри необходимости должна быть до этой страницы, чтобы проверить предоставленные параметры, и предпринять соответствующие действия и показать соответствующие сообщения.

1 голос
/ 16 октября 2011

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

Я предполагаю, что 'Опции матрицы 'вы имеете в виду параметры URL / GET, такие как:

http://domain.com/page/?option1=value&option2=value..

Вместо 404, если они вводят неправильную комбинацию параметров, почему бы не использовать по умолчанию базовый URL / шаблон (http://domain.com/page/) с ошибкойсообщение «Option1 может быть только x, y, z». Таким образом, они представлены со знакомой страницей и могут повторить свой выбор, не возвращаясь назад со страницы 404 (и это не так смущает, почему это не так.не работает).

Вы можете использовать среду обмена сообщениями django , чтобы легко сделать это (я делал это в прошлом). Передавайте сообщение об ошибке в шаблон, когда вы проверяетепараметры в представлении.

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