Защо Django не предава съобщения за грешка с изгледа 404 по подразбиране?

(Контекст: Все още съм много нов както в Django, така и в уеб разработката.)

1) Може ли някой да обясни мотивите за следното твърдение? Това 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 web development и Matrix URIs (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