De ce Django nu transmite mesaje de eroare cu vizualizarea implicită 404?

(Context: sunt încă foarte nou atât în ​​Django, cât și în dezvoltarea web.)

1) Ar putea cineva să explice raționamentul următoarei afirmații? Această întrebare/ A a răspuns la întrebarea cum să se ocupe, dar nu de ce ar putea fi o idee bună/rea.

Documentele indică „Pagina_nu_găsită vizualizarea ar trebui să fie suficientă pentru 99% din aplicațiile Web, dar dacă doriți să o înlocuiți, puteți specifica handler404 în URLconf".

Adică, vizualizarea page_not_found transmite numai adresa URL solicitată și ignoră orice mesaj pe care îl furnizați atunci când ridicați o excepție. Mi se pare că a avea opțiunea de a oferi indicii utile pentru șablonul 404.html în mod implicit ar fi bine pentru toată lumea.

2) În prezent, fac o vizualizare personalizată, astfel încât să pot transmite mesaje utile pentru următoarea situație. Există vreun motiv pentru care nu ar trebui?

Folosesc adrese URL matrice, astfel încât resursa de bază este o adresă URL ierarhică normală, urmată de opțiuni de matrice în formatul de bază: ;filter_type1=item:value, item:value;filter_type2=item:value...

Prin urmare, este destul de ușor să furnizați mesaje utile bazate pe cât de departe ajunge analizarea înainte de a avea o eroare. Mi se pare util să transmit un mesaj precum următorul:

  • „Filter_types permise sunt: ​​type1, type2, type3.” sau
  • „Elementele permise pentru filter_type a sunt: ​​item1, item2, item3.”

Scuze dacă am ratat această explicație în altă parte. M-am uitat și am "=follow" no re&pli google django-users, dar nu a primit răspunsuri.


django
person KobeJohn    schedule 16.10.2011    source sursă
comment
Se pare că la întrebare s-a răspuns doar indirect. Cu toate acestea, pe baza răspunsurilor de până acum, trebuie să presupun că răspunsul este: dacă aveți nevoie de un mesaj de eroare într-un 404, o faceți greșit.   -  person KobeJohn    schedule 20.10.2011

Răspunsuri (3)


arrow_upward
1
arrow_downward

Nu sunt chiar sigur care este întrebarea. Vizualizarea page_not_found este de bază în mod implicit, deoarece există nu sunt atât de multe situații în care trebuie să explicați de ce pagina nu a fost găsită, cu excepția faptului că nu a fost.

Presupun că prin „opțiuni de matrice” vă referiți la parametri URL/GET precum:

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

În loc să arunce un 404 dacă introduc o combinație incorectă de parametru, de ce să nu se utilizeze implicit adresa URL/șablon de bază (http://domain.com/page/) cu un mesaj de eroare care spune „Opțiunea1 poate fi doar x,y,z ". În acest fel, li se prezintă o pagină familiară și își pot reîncerca selecția fără a fi nevoiți să navigheze înapoi de la o pagină 404 (și nu este atât de confuz de ce nu a funcționat).

Puteți utiliza cadru de mesagerie al django pentru a realiza acest lucru cu ușurință (am făcut asta în trecut). Transmiteți un mesaj de eroare șablonului când verificați parametrii din vizualizare.

person Timmy O'Mahony    schedule 16.10.2011
comment
... este de bază în mod implicit, deoarece nu există atât de multe situații în care trebuie să explicați de ce nu a fost găsită pagina... Am văzut doar afirmații precum a dvs. și documentația că nu există multe situații pentru mesaj. Pot să accept în totalitate că poate este adevărat, dar caut mai mult decât o afirmație. Explicația dvs. despre a doua parte mă ajută spunând că poate nu este greșit să afișați un mesaj de eroare, dar că ar putea exista o modalitate mai bună de a face acest lucru. Multumesc pentru raspunsul tau! - person KobeJohn; 17.10.2011
comment
Ce motive vă puteți gândi pentru care o pagină nu a putut fi găsită. (1) un link a fost întrerupt, (2) un utilizator a introdus-o greșit (vezi #1). Dacă există alte motive, cum ar fi fost introduse date invalide, nu ar trebui să fie un 404. Utilizați alte coduri de răspuns HTTP pentru a arăta că un răspuns a eșuat. 409: date conflictuale, 403: interzis etc. - person Matthew Schinckel; 17.10.2011
comment
Destul de corect. Eu însumi m-am întrebat despre asta. Similar cu comentariul meu la Matthew, să presupunem că parametrii de filtru/ordine din adresa URL par a fi deformați. Nu este 404? Poate latră în copacul greșit. M-am uitat prin toate răspunsurile HTTP și nu am găsit unul mai potrivit. - person KobeJohn; 19.10.2011
comment
Aș returna un 409: Conflict. (Sau un simplu 400: Eroare). Dacă doar redați HTML, atunci ați returna un 200, dar datele paginii arată că există o eroare. (Majoritatea programării aplicațiilor mele web se bazează pe API, unde răspunsurile din seria 4xx pot avea și au un corp.) - person Matthew Schinckel; 19.10.2011

arrow_upward
1
arrow_downward

Dacă datele dvs. vin ca:

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

Atunci faci gresit :)

Apoi, trebuie să utilizați expresii regulate pentru a analiza datele care urmează să fie procesate.

Unii oameni, când se confruntă cu o problemă, gândesc „Știu, voi folosi expresii regulate”. Acum au două probleme.

(Zawinski, 1997)

În schimb, așa cum sugerează pastylegs, utilizați parametrii GET.

Și mai bine, folosiți gestionarea formularelor django și:

  • creați un formular, care are reguli de validare
  • redați pagina de intrare din formularul respectiv
  • analizați intrarea utilizatorului folosind formularul
  • afișați datele dacă formularul a fost valid, altfel afișați erorile de validare alături de introducerea utilizatorului

Puteți face acest lucru cu solicitări GET sau solicitări POST. POST are avantajul de a avea adrese URL „curate” și corpuri de date mai lungi. GET înseamnă că adresele URL pot fi marcate.

Toate acestea se rezumă la utilizarea părților potrivite ale cadrului pentru sarcinile potrivite. Dirijarea adresei URL folosește expresii regulate pentru a afla ce adresă URL atinge fiecare vizualizare. Cu cât faci modelele de adrese URL mai simplu, cu atât vor fi mai ușor de întreținut. Intrarea utilizatorului ar trebui să fie gestionată de formulare.

person Matthew Schinckel    schedule 17.10.2011
comment
Ideea de a face greșit. Doar pentru a explica... după ce ați citit dezvoltarea web RESTful și URI-uri Matrix (1996) de Tim Berners-Lee Am fost inspirat să scriu un sistem pentru manipularea URI-urilor matriceale cu formatul punct și virgulă. Este un sistem mai flexibil decât interogarea, dar pur și simplu nu este implementat în cadre, așa că da, are nevoie de analizare :) - person KobeJohn; 19.10.2011
comment
În ceea ce privește conținutul parametrilor, aceștia nu sunt introduși de utilizator în sine. Sunt filtre și direcții de ordonare pentru listele de date care vor apărea pe pagină. Ele pot fi modificate de utilizator dacă sunt furnizate unele comenzi. Deci, în această situație, să presupunem că convertesc la utilizarea unui șir de interogare și a parametrilor GET, care este calea corectă, de ex. parametrii de filtru/ordine incorect în șirul de interogare? - person KobeJohn; 19.10.2011
comment
Poziția mea este că, dacă utilizatorul selectează lucruri și apoi acest lucru afectează datele primite, atunci este introdus de utilizator. Este probabil validat oarecum de partea client a aplicației dvs., dar ar trebui să fie totuși validat de server. În ceea ce privește comanda: dacă utilizați mapări (și pentru a folosi un formular, o veți), asta dispare. Date incorecte: -› redați din nou formularul arătând cum intră în conflict datele. - person Matthew Schinckel; 19.10.2011
comment
Pentru a fi mai clar: nu vă fixați pe faptul că un formular este de obicei câmpuri HTML. Dacă puteți, faceți ca controalele paginii dvs. să actualizeze câmpurile ascunse dintr-un element ‹formular›, care este apoi postat. - person Matthew Schinckel; 19.10.2011

arrow_upward
1
arrow_downward

Cred că motivul pentru care întâmpinați probleme este că încercați să amestecați 2 probleme diferite.

În primul rând, este problema dacă pagina reală a fost găsită sau nu.
În al doilea rând, este problema dacă parametrii furnizați au fost validi sau nu.

Deci, dacă adresa URL (parțială) este:

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

Dacă pagina /whatever/default este nu este găsită, vi se va (ar trebui) să vi se afișeze un mesaj de eroare de tip "404 Page not found". În acest caz, nu puteți spune dacă parametrii sau valorile furnizate au fost corecte. Pagina solicitată nu există, așa că nu știți pentru ce pagină au fost destinați parametrii. Nici măcar nu puteți presupune că a fost specificat domain name corect. Pot exista multe domenii, adrese URL și pagini arbitrare în care parametrii sunt validi și multe altele în care parametrii sunt invalidi.

Dacă pagina /whatever/default este găsită, atunci:
Dacă specificarea parametrilor greșiți ar putea face ca pagina respectivă să încarce/redirecționeze o pagină inexistentă, atunci acest lucru ar trebui să fie împiedicat de pagina respectivă. Dacă este necesar, trebuie să revină acelei pagini să valideze parametrii furnizați și să ia măsurile adecvate și să arate mesajele adecvate.

person Kevin Fegan    schedule 24.02.2013