Kāpēc Django nenodod kļūdu ziņojumus ar noklusējuma 404 skatu?

(Konteksts: es joprojām esmu ļoti iesācējs gan Django, gan tīmekļa izstrādē.)

1) Vai kāds varētu izskaidrot šāda apgalvojuma pamatojumu? Šis jautājums/ A atbildēja uz jautājumu kā ar to rīkoties, bet ne to, kāpēc tā varētu būt laba/slikta ideja.

Dokumentos ir norādīts: "The page_not_found skatam vajadzētu būt pietiekamam 99% tīmekļa lietojumprogrammu, bet, ja vēlaties to ignorēt, savā URLconf varat norādīt handler404.

Tas nozīmē, ka skats page_not_found nodod tikai pieprasīto URL un ignorē visus ziņojumus, ko sniedzat, izvirzot izņēmumu. Man šķiet, ka opcija pēc noklusējuma sniegt noderīgus padomus veidnei 404.html būtu noderīga ikvienam.

2) Pašlaik es veidoju pielāgotu skatu, lai varētu nodot noderīgus ziņojumus tālāk norādītajā situācijā. Vai ir kāds iemesls, kāpēc man nevajadzētu?

Es izmantoju matricas URL, tāpēc bāzes resurss ir parasts hierarhisks URL, kam seko matricas opcijas pamata formātā: ;filter_type1=item:value, item:value;filter_type2=item:value...

Tāpēc ir diezgan vienkārši sniegt noderīgus ziņojumus, pamatojoties uz to, cik tālu parsēšana sasniedz, pirms rodas kļūda. Man šķiet noderīgi nodot tālāk šādu ziņojumu:

  • "Atļautie filtru veidi ir: tips1, tips2, tips3." vai
  • "Atļautie vienumi filtram a ir: item1, item2, item3."

Atvainojos, ja palaidu garām šo skaidrojumu citur. Esmu apskatījis un onrelfern=r1"low google django-users, taču nesaņēma atbildes.


django
person KobeJohn    schedule 16.10.2011    source avots
comment
Šķiet, ka uz jautājumu ir sniegta tikai netieša atbilde. Tomēr, pamatojoties uz līdzšinējām atbildēm, man jāpieņem, ka atbilde ir šāda: ja jums ir nepieciešams kļūdas ziņojums 404, jūs to darāt nepareizi.   -  person KobeJohn    schedule 20.10.2011

Atbildes (3)


arrow_upward
1
arrow_downward

Es neesmu īsti pārliecināts, kāds ir jautājums. Skats page_not_found pēc noklusējuma ir pamata skats, jo Vai nav tik daudz situāciju, kad jāpaskaidro, kāpēc lapa netika atrasta, izņemot to, ka tā netika atrasta.

Es pieņemu, ka ar “matricas opcijām” jūs domājat URL/GET parametrus, piemēram:

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

Tā vietā, lai ievadītu 404, ja viņi ievada nepareizu parametru kombināciju, kāpēc gan neizmantot pamata URL/veidni (http://domain.com/page/) ar kļūdas ziņojumu “Option1 var būt tikai x,y,z ". Tādā veidā viņiem tiek parādīta pazīstama lapa, un viņi var vēlreiz mēģināt izvēlēties, nevirzoties atpakaļ no 404. lapas (un tas nav tik mulsinoši, kāpēc tā nedarbojās).

Lai to viegli paveiktu, varat izmantot django ziņojumapmaiņas sistēmu (es esmu tas tika darīts agrāk). Pārbaudot parametrus skatā, nosūtiet veidnei kļūdas ziņojumu.

person Timmy O'Mahony    schedule 16.10.2011
comment
...pēc noklusējuma ir pamata, jo nav tik daudz situāciju, kurās jums jāpaskaidro, kāpēc lapa netika atrasta... Esmu redzējis tikai tādus apgalvojumus kā jūsējais un dokumentācija, ka nav daudz situāciju ziņa. Es varu pilnībā pieņemt, ka tā, iespējams, ir patiesība, bet es meklēju vairāk nekā apgalvojumu. Jūsu skaidrojums otrajā daļā man palīdz, sakot, ka kļūdas ziņojuma rādīšana var nebūt nepareizi, bet var būt labāks veids, kā to izdarīt. Paldies par atbildi! - person KobeJohn; 17.10.2011
comment
Kādu iemeslu dēļ lapu nevarēja atrast? (1) saite tika bojāta, (2) lietotājs to ierakstīja nepareizi (sk. #1). Ja ir kādi citi iemesli, piemēram, tika ievadīti nederīgi dati, tam nevajadzētu būt 404. Izmantojiet citus HTTP atbildes kodus, lai parādītu, ka atbilde neizdevās. 409: pretrunīgi dati, 403: aizliegts utt. - person Matthew Schinckel; 17.10.2011
comment
Godīgi. Pats par šo esmu aizdomājies. Līdzīgi kā mans komentārs Metjū, pieņemsim, ka filtra/pasūtīšanas parametri URL ir nepareizi veidoti. Vai tas nav 404? Varbūt es reju nepareizo koku. Es izskatīju visas HTTP atbildes un neatradu piemērotāku. - person KobeJohn; 19.10.2011
comment
Es atgrieztu 409: Konflikts. (Vai arī vienkāršs 400: kļūda). Tomēr, ja jūs tikai renderējat HTML, jūs atgriezīsit 200, taču lapas dati liecina, ka ir kļūda. (Lielākā daļa manu tīmekļa lietojumprogrammu programmēšanas ir balstīta uz API, kur 4xx sērijas atbildēm var būt un ir pamatteksts.) - person Matthew Schinckel; 19.10.2011

arrow_upward
1
arrow_downward

Ja jūsu dati tiek saņemti, piemēram:

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

Tad tu dari nepareizi :)

Pēc tam jums ir jāizmanto regulārās izteiksmes, lai parsētu apstrādājamos datus.

Daži cilvēki, saskaroties ar problēmu, domā: "Es zinu, es izmantošu regulāras izteiksmes". Tagad viņiem ir divas problēmas.

(Zavinskis, 1997)

Tā vietā, kā iesaka pastylegs, izmantojiet GET parametrus.

Vēl labāk, izmantojiet django formu apstrādi un:

  • izveidot veidlapu, kurai ir validācijas noteikumi
  • renderējiet ievades lapu no šīs veidlapas
  • parsējiet lietotāja ievadīto informāciju, izmantojot veidlapu
  • parādīt datus, ja forma bija derīga, pretējā gadījumā kopā ar lietotāja ievadi tiek parādītas validācijas kļūdas

To var izdarīt, izmantojot GET pieprasījumus vai POST pieprasījumus. POST priekšrocība ir “tīri” vietrāži URL un garāks datu korpuss. GET nozīmē, ka URL var pievienot grāmatzīmēm.

Tas viss ir saistīts ar pareizo ietvara daļu izmantošanu pareizajiem uzdevumiem. URL maršrutēšana izmanto regulārās izteiksmes, lai noteiktu, kurš URL sasniedz kādu skatu. Jo vienkāršākus URL modeļus izveidosit, jo vieglāk tos būs uzturēt. Lietotāja ievade ir jāapstrādā veidlapās.

person Matthew Schinckel    schedule 17.10.2011
comment
Uzskats, ka dari to nepareizi. Lai paskaidrotu... pēc RESTful tīmekļa izstrādes un Matrix URI (1996) izlasīšanas Tims Berners-Lī Mani iedvesmoja uzrakstīt sistēmu matricas URI apstrādei semikola formātā. Tā ir elastīgāka sistēma nekā vaicājums, taču tā vienkārši nav ieviesta ietvaros, tāpēc jā, tai ir nepieciešama parsēšana :) - person KobeJohn; 19.10.2011
comment
Kas attiecas uz parametru saturu, tie paši par sevi nav lietotāja ievade. Tie ir filtri un secības norādes datu sarakstiem, kas tiks parādīti lapā. Lietotājs tos var mainīt, ja ir nodrošinātas dažas vadīklas. Tātad šajā situācijā, pieņemsim, ka es pāreju uz vaicājuma virknes un GET parametru izmantošanu, kāds ir pareizais veids, kā piem. nepareizi veidoti filtra/pasūtīšanas parametri vaicājuma virknē? - person KobeJohn; 19.10.2011
comment
Mana nostāja ir tāda, ka, ja lietotājs atlasa lietas un tad tas ietekmē ienākošos datus, tad tā ir lietotāja ievade. Iespējams, to zināmā mērā ir apstiprinājusi jūsu lietojumprogrammas klienta puse, taču tā joprojām ir jāvalidē serverim. Kas attiecas uz pasūtīšanu: ja izmantojat kartējumus (un, lai izmantotu veidlapu, jūs to darīsit), tas pazūd. Nepareizi dati: -› atkārtoti renderējiet veidlapu, parādot datu konfliktus. - person Matthew Schinckel; 19.10.2011
comment
Lai padarītu to skaidrāku: neuztraucieties par to, ka veidlapa parasti ir HTML lauki. Ja varat, lieciet lapas vadīklām atjaunināt slēptos laukus veidlapas elementā, kas pēc tam tiek publicēts. - person Matthew Schinckel; 19.10.2011

arrow_upward
1
arrow_downward

Es domāju, ka iemesls, kāpēc jums ir grūti to saprast, ir tas, ka jūs mēģināt sajaukt 2 dažādas problēmas.

Pirmkārt, tas ir jautājums par to, vai faktiskā lapa tika atrasta.
Otrkārt, ir jautājums par to, vai norādītie parametri bija derīgi vai nē.

Tātad, ja (daļējais) URL ir:

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

Ja lapa /whatever/default nav nav atrasta, jums (vajadzētu) parādīt "404 Page not found" veida kļūdas ziņojumu. Šajā gadījumā jūs nevarat pateikt, vai norādītie parametri vai vērtības bija pareizi. Pieprasītā lapa neeksistē, tāpēc jūs nezināt, kurai lapai parametri bija paredzēti. Jūs pat nevarat pieņemt, ka tika norādīts pareizais domain name. Var būt daudz patvaļīgu domēnu, vietrāžu URL un lapu, kur parametri ir derīgi, un daudzi citi, kur parametri nav derīgi.

Ja lapa /whatever/default tiek atrasta, tad:
Ja, norādot nepareizus parametrus, šī lapa var ielādēt/novirzīt neesošu lapu, tad šai lapai tas ir jānovērš. Ja nepieciešams, šai lapai ir jāapstiprina sniegtie parametri, jāveic atbilstošas ​​darbības un jāparāda atbilstoši ziņojumi.

person Kevin Fegan    schedule 24.02.2013