Pse Django nuk transmeton mesazhe gabimi me pamjen e paracaktuar 404?

(Konteksti: Unë jam ende shumë i ri si në Django ashtu edhe në zhvillimin e uebit.)

1) A mund të shpjegojë dikush arsyetimin për deklaratën e mëposhtme? Kjo pyetje/ A iu përgjigj pyetjes se si të merret me të, por jo pse mund të jetë një ide e mirë/e keqe.

Dokumentet thonë, "The page_not_found pamja duhet të mjaftojë për 99% të aplikacioneve në ueb, por nëse doni ta anashkaloni atë, mund të specifikoni handler404 në URLconf-in tuaj".

Kjo do të thotë, pamja page_not_found kalon vetëm në URL-në e kërkuar dhe injoron çdo mesazh që jepni kur bëni një përjashtim. Më duket se të kesh opsionin për të ofruar këshilla të dobishme për shabllonin 404.html si parazgjedhje do të ishte mirë për të gjithë.

2) Aktualisht po bëj një pamje të personalizuar në mënyrë që të mund të përcjell mesazhe të dobishme për situatën e mëposhtme. A ka ndonjë arsye që nuk duhet të bëj?

Unë jam duke përdorur URL-të e matricës, kështu që burimi bazë është një URL hierarkike normale e ndjekur nga opsionet e matricës në formatin bazë: ;filter_type1=item:value,item:value;filter_type2=article:value...

Pra, është mjaft e lehtë të ofrohen mesazhe të dobishme bazuar në atë se sa larg shkon analiza përpara se të ketë një gabim. Më duket e dobishme të përcjell një mesazh të tillë si vijon:

  • "Llojet e_filtrave të lejuara janë: type1, type2, type3." ose
  • "Artikujt e lejuar për filtrin_lloj a janë: artikulli1, artikulli2, artikulli3."

Më falni nëse e kam humbur këtë shpjegim diku tjetër. E kam shikuar dhe por nuk mori përgjigje.


django
person KobeJohn    schedule 16.10.2011    source burimi
comment
Duket sikur pyetjes i është përgjigjur vetëm në mënyrë indirekte. Megjithatë, bazuar në përgjigjet e deritanishme, duhet të supozoj se përgjigja është: nëse keni nevojë për një mesazh gabimi në një 404, po e bëni gabim.   -  person KobeJohn    schedule 20.10.2011

Përgjigjet (3)


arrow_upward
1
arrow_downward

Nuk jam vërtet i sigurt se cila është pyetja. Pamja page_not_found është bazë si parazgjedhje sepse atje nuk janë aq shumë situata ku duhet të shpjegoni pse faqja nuk u gjet përveç se nuk u gjet.

Unë supozoj se me 'opsionet e matricës' nënkuptoni parametrat URL/GET si:

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

Në vend që të hedhin një 404 nëse futin një kombinim të gabuar të parametrave, pse të mos parazgjedhni në url/shabllonin bazë (http://domain.com/page/) me një mesazh gabimi që thotë "Opsioni 1 mund të jetë vetëm x, y, z ". Në këtë mënyrë ata paraqiten me një faqe të njohur dhe mund të riprovojnë përzgjedhjen e tyre pa pasur nevojë të kthehen nga një faqe 404 (dhe nuk është aq konfuze se pse nuk funksionoi).

Ju mund të përdorni kornizën e mesazheve të django për ta realizuar me lehtësi këtë (kam bërë kështu në të kaluarën). Kaloni një mesazh gabimi në shabllon kur jeni duke kontrolluar parametrat në pamje.

person Timmy O'Mahony    schedule 16.10.2011
comment
...është bazë si parazgjedhje sepse nuk ka shumë situata ku duhet të shpjegoni pse nuk u gjet faqja... Unë kam parë vetëm pohime të tilla si tuajat dhe dokumentacionin se nuk ka shumë situata për mesazh. Mund ta pranoj plotësisht se ndoshta është e vërtetë, por kërkoj më shumë se pohim. Shpjegimi juaj për pjesën e dytë më ndihmon duke thënë se mund të mos jetë gabim të tregosh një mesazh gabimi, por se mund të ketë një mënyrë më të mirë për ta bërë atë. Faleminderit për përgjigjen tuaj! - person KobeJohn; 17.10.2011
comment
Cilat arsye mund të mendoni përse nuk mund të gjendej një faqe. (1) një lidhje është prishur, (2) një përdorues e ka shkruar gabimisht (shih #1). Nëse ka ndonjë arsye tjetër, si p.sh. janë futur të dhëna të pavlefshme, nuk duhet të jetë një 404. Përdor kode të tjera përgjigjeje HTTP për të treguar se një përgjigje dështoi. 409: të dhëna kontradiktore, 403: e ndaluar, etj. - person Matthew Schinckel; 17.10.2011
comment
Mjaft e drejtë. Unë vetë jam pyetur për këtë. Ngjashëm me komentin tim për Matthew, le të themi se parametrat e filtrit/rendit në URL duket se janë të keqformuar. A nuk është ai 404? Ndoshta po leh pemën e gabuar. Shikova të gjitha përgjigjet HTTP dhe nuk gjeta një më të përshtatshme. - person KobeJohn; 19.10.2011
comment
Do të ktheja një 409: Konflikt. (Ose një 400 e thjeshtë: Gabim). Megjithatë, nëse thjesht po jepni HTML, atëherë do të ktheni një 200, por të dhënat e faqes tregojnë se ka një gabim. (Shumica e programimit tim të aplikacionit në ueb është i bazuar në API, ku përgjigjet e serisë 4xx mund dhe kanë një trup.) - person Matthew Schinckel; 19.10.2011

arrow_upward
1
arrow_downward

Nëse të dhënat tuaja vijnë si:

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

Atëherë po e bëni gabim :)

Më pas duhet të përdorni shprehje të rregullta për të analizuar të dhënat që do të përpunohen.

Disa njerëz, kur përballen me një problem, mendojnë "E di, do të përdor shprehje të rregullta". Tani ata kanë dy probleme.

(Zawinski, 1997)

Në vend të kësaj, siç sugjeron pastylegs, përdorni parametrat GET.

Edhe më mirë, përdorni trajtimin e formës django dhe:

  • krijoni një formular që ka rregulla vërtetimi
  • jepni faqen hyrëse nga ajo formë
  • analizoni hyrjen e përdoruesit duke përdorur formularin
  • shfaqni të dhënat nëse forma ishte e vlefshme, përndryshe shfaqni gabimet e vlefshmërisë së bashku me hyrjen e përdoruesit

Ju mund ta bëni këtë me kërkesat GET, ose kërkesat POST. POST ka avantazhin e të paturit url 'të pastra' dhe trup më të gjatë të të dhënave. GET do të thotë që url-të mund të shënohen.

E gjithë kjo varet nga përdorimi i pjesëve të duhura të kornizës për detyrat e duhura. Drejtimi i URL-së përdor shprehje të rregullta për të përcaktuar se cila URL godet cilën pamje. Sa më të thjeshta t'i bëni modelet e url-ve, aq më lehtë do të jenë për t'u ruajtur. Të dhënat e përdoruesit duhet të trajtohen nga formularët.

person Matthew Schinckel    schedule 17.10.2011
comment
Pika marrë për të bërë atë gabim. Vetëm për të shpjeguar... pasi lexoni zhvillimin e uebit RESTful dhe URI-të e matricës (1996) nga Tim Berners-Lee Unë u frymëzova për të shkruar një sistem për trajtimin e URI-ve të matricës me formatin pikëpresje. Është një sistem më fleksibël se pyetja, por thjesht nuk zbatohet në korniza, kështu që po, ka nevojë për analizë :) - person KobeJohn; 19.10.2011
comment
Sa i përket përmbajtjes së parametrave, ato nuk janë hyrje të përdoruesit në vetvete. Ato janë filtra dhe udhëzime të renditjes për listat e të dhënave që do të shfaqen në faqe. Ato mund të modifikohen nga përdoruesi nëse ofrohen disa kontrolle. Pra, në këtë situatë, le të themi se unë konvertohem në përdorimin e një vargu pyetësor dhe parametrave GET, cila është mënyra e duhur për të bërë p.sh. Parametrat e filtrit/rendit të keqformuar në vargun e pyetjes? - person KobeJohn; 19.10.2011
comment
Pozicioni im është që nëse përdoruesi zgjedh gjërat, dhe më pas kjo ndikon në të dhënat hyrëse, atëherë është hyrje e përdoruesit. Ka të ngjarë të vërtetohet disi nga ana e klientit të aplikacionit tuaj, por duhet të vërtetohet ende nga serveri. Sa për porositjen: nëse përdorni mapping (dhe për të përdorur një formular, do ta bëni), kjo shkon larg. Të dhëna të pasakta: -› riparaqisni formularin që tregon se si bien ndesh të dhënat. - person Matthew Schinckel; 19.10.2011
comment
Për ta bërë më të qartë: mos u fiksoni me faktin se një formë është zakonisht fusha HTML. Nëse mundeni, bëni që kontrollet e faqes suaj të përditësojnë fushat e fshehura brenda një elementi ‹form›, i cili më pas postohet. - person Matthew Schinckel; 19.10.2011

arrow_upward
1
arrow_downward

Unë mendoj se arsyeja pse keni probleme për ta kuptuar këtë është se po përpiqeni të përzieni 2 çështje të ndryshme.

Së pari, është çështja nëse faqja aktuale u gjet apo jo.
Së dyti, është çështja nëse parametrat e dhënë ishin të vlefshëm apo jo.

Pra, nëse url (i pjesshëm) është:

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

Nëse faqja /whatever/default nuk gjendet, do t'ju shfaqet (duhet) një mesazh gabimi i llojit "404 Page not found". Në këtë rast, nuk mund të dallosh nëse parametrat ose vlerat e dhëna ishin të sakta. Faqja e kërkuar nuk ekziston, kështu që ju nuk e dini se për cilën faqe janë menduar parametrat. Ju as nuk mund të supozoni se ishte specifikuar domain name e saktë. Mund të ketë shumë domene, url dhe faqe arbitrare ku parametrat janë të vlefshëm dhe shumë të tjera ku parametrat janë të pavlefshëm.

Nëse faqja /whatever/default gjendet, atëherë:
Nëse specifikimi i parametrave të gabuar mund të shkaktojë që ajo faqe të ngarkojë/ridrejtojë një faqe që nuk ekziston, atëherë kjo duhet të parandalohet nga ajo faqe. Nëse është e nevojshme, duhet të jetë në dorën e asaj faqe për të vërtetuar parametrat e dhënë, për të ndërmarrë veprimet e duhura dhe për të shfaqur mesazhet e duhura.

person Kevin Fegan    schedule 24.02.2013