Почему Django не передает сообщения об ошибках с представлением 404 по умолчанию?

(Контекст: я все еще новичок как в Django, так и в веб-разработке.)

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

Документация гласит: "Страница_не_найдена view должно хватить для 99% веб-приложений, но если вы хотите переопределить его, вы можете указать handler404 в своем URLconf".

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

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

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

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

  • «Разрешенные типы_фильтров: тип1, тип2, тип3». или
  • «Разрешенные элементы для filter_type a: item1, item2, item3».

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


django
person KobeJohn    schedule 16.10.2011    source источник
comment
Такое ощущение, что на вопрос был дан лишь косвенный ответ. Однако, основываясь на ответах до сих пор, я должен предположить, что ответ таков: если вам нужно сообщение об ошибке в 404, вы делаете это неправильно.   -  person KobeJohn    schedule 20.10.2011

Ответы (3)


arrow_upward
1
arrow_downward

Я не совсем уверен, в чем вопрос. Представление 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, чтобы легко выполнить это (я делал это в прошлом). Передайте шаблону сообщение об ошибке при проверке параметров в представлении.

person Timmy O'Mahony    schedule 16.10.2011
comment
... является базовым по умолчанию, потому что не так много ситуаций, когда вам нужно объяснить, почему страница не была найдена... Я видел только такие утверждения, как ваше и документацию, что не так много ситуаций для сообщение. Я могу полностью согласиться с тем, что, возможно, это правда, но я ищу большего, чем утверждение. Ваше объяснение во второй части помогает мне, говоря, что показывать сообщение об ошибке может быть неправильно, но может быть лучший способ сделать это. Спасибо за Ваш ответ! - person KobeJohn; 17.10.2011
comment
Какие вы можете придумать причины, по которым страница не может быть найдена. (1) ссылка не работает, (2) пользователь ввел ее неправильно (см. № 1). Если есть какие-либо другие причины, например, были введены неверные данные, это не должно быть 404. Используйте другие коды ответа HTTP, чтобы показать, что ответ не выполнен. 409: противоречивые данные, 403: запрещено и т. д. - person Matthew Schinckel; 17.10.2011
comment
Справедливо. Я сам задавался этим вопросом. Как и в моем комментарии Мэтью, скажем, параметры фильтра/порядка в URL-адресе имеют неверный формат. Это не 404? Может быть, я лаю не на то дерево. Я просмотрел все ответы HTTP и не нашел более подходящего. - person KobeJohn; 19.10.2011
comment
Я бы вернул 409: Конфликт. (Или просто 400: Ошибка). Однако, если вы просто визуализируете HTML, вы вернете 200, но данные страницы показывают, что произошла ошибка. (Большая часть моего программирования веб-приложений основана на API, где ответы серии 4xx могут иметь и действительно имеют тело.) - person Matthew Schinckel; 19.10.2011

arrow_upward
1
arrow_downward

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

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

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

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

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

(Завински, 1997)

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

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

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

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

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

person Matthew Schinckel    schedule 17.10.2011
comment
Замечание, сделанное неправильно. Просто чтобы объяснить... после прочтения веб-разработки RESTful и Matrix URI (1996) от Тим Бернерс-Ли Меня вдохновило написать систему для обработки матричных URI в формате с запятой. Это более гибкая система, чем запрос, но она просто не реализована в фреймворках, так что да, ее нужно синтаксически проанализировать :) - person KobeJohn; 19.10.2011
comment
Что касается содержания параметров, то они сами по себе не являются вводом пользователем. Это фильтры и указания по порядку для списков данных, которые будут отображаться на странице. Они могут быть изменены пользователем, если предусмотрены некоторые элементы управления. Итак, в этой ситуации, скажем, я перехожу к использованию строки запроса и параметров GET, как правильно поступить, например. искаженные параметры фильтра/порядка в строке запроса? - person KobeJohn; 19.10.2011
comment
Моя позиция такова, что если пользователь что-то выбирает, а потом это влияет на входящие данные, то это пользовательский ввод. Скорее всего, это несколько проверяется на стороне клиента вашего приложения, но все равно должно проверяться сервером. Что касается порядка: если вы используете сопоставления (и для использования формы вы будете), это исчезнет. Неверные данные: -› перерисуйте форму, показав, как данные конфликтуют. - person Matthew Schinckel; 19.10.2011
comment
Чтобы было понятнее: не зацикливайтесь на том факте, что форма обычно представляет собой HTML-поля. Если вы можете, сделайте так, чтобы элементы управления вашей страницы обновляли скрытые поля в элементе ‹form›, который затем публикуется. - person Matthew Schinckel; 19.10.2011

arrow_upward
1
arrow_downward

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

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

Итак, если (частичный) URL-адрес:

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

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

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

person Kevin Fegan    schedule 24.02.2013