Miksi Django ei välitä virheilmoituksia oletusarvoisella 404-näkymällä?

(Konteksti: Olen vielä hyvin uusi sekä Djangossa että verkkokehityksessä.)

1) Voisiko joku selittää seuraavan väitteen perustelut? Tämä K/ A vastasi kysymykseen miten käsitellä sitä, mutta ei miksi se voisi olla hyvä/huono idea.

Dokumenteissa lukee "The page_not_found näkymän pitäisi riittää 99 %:lle verkkosovelluksista, mutta jos haluat ohittaa sen, voit määrittää handler404:n URLconf-tiedostossa.

Toisin sanoen page_not_found -näkymä välittää vain pyydetyn URL-osoitteen ja jättää huomiotta kaikki viestit, jotka annat poikkeuksen yhteydessä. Minusta näyttää, että vaihtoehto tarjota hyödyllisiä vihjeitä 404.html-malliin oletuksena olisi hyvä kaikille.

2) Olen parhaillaan tekemässä mukautettua näkymää, jotta voin välittää hyödyllisiä viestejä seuraavassa tilanteessa. Onko jokin syy, miksi minun ei pitäisi?

Käytän matriisi-URL-osoitteita, joten perusresurssi on normaali hierarkkinen URL-osoite, jota seuraa matriisivaihtoehdot perusmuodossa: ;filter_type1=item:value, item:value;filter_type2=item:value...

Joten on melko helppoa antaa hyödyllisiä viestejä sen perusteella, kuinka pitkälle jäsennys pääsee ennen virhettä. Minusta tuntuu auttavan välittämään seuraavanlaisen viestin:

  • "Sallitut suodatintyypit ovat: tyyppi1, tyyppi2, tyyppi3." tai
  • "Sallitut kohteet filter_typelle a ovat: item1, item2, item3."

Pahoittelut, jos tämä selitys on unohtunut muualta. Olen katsonut ja nokrelfern=1"low google django-users, mutta ei saanut vastauksia.


django
person KobeJohn    schedule 16.10.2011    source lähde
comment
Tuntuu, että kysymykseen on vastattu vain epäsuorasti. Tähänastisten vastausten perusteella minun on kuitenkin oletettava, että vastaus on: jos tarvitset virheilmoituksen 404:ään, teet sen väärin.   -  person KobeJohn    schedule 20.10.2011

Vastaukset (3)


arrow_upward
1
arrow_downward

En ole varma, mikä kysymys on. page_not_found -näkymä on oletuksena perusnäkymä, koska ei ole niin paljon tilanteita, joissa sinun täytyy selittää, miksi sivua ei löytynyt, paitsi että sitä ei löytynyt.

Oletan, että "matriisivaihtoehdoilla" tarkoitat URL/GET-parametreja, kuten:

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

Sen sijaan, että heittäisivät 404:n, jos he syöttävät väärän parametriyhdistelmän, miksi et käyttäisi oletuksena perus-URL-osoitetta/mallia (http://domain.com/page/) ja saat virheilmoituksen "Vaihtoehto1 voi olla vain x,y,z ". Näin heille esitellään tuttu sivu ja he voivat yrittää valintaansa uudelleen ilman, että heidän tarvitsee siirtyä takaisin 404-sivulta (eikä ole niin hämmentävää, miksi se ei toiminut).

Voit tehdä tämän helposti käyttämällä djangon viestikehystä (olen tehnyt niin aiemmin). Välitä virheilmoitus malliin, kun tarkistat näkymän parametreja.

person Timmy O'Mahony    schedule 16.10.2011
comment
...on oletusarvoisesti perus, koska ei ole niin montaa tilanteita, joissa sinun täytyy selittää, miksi sivua ei löydy... Olen nähnyt vain väitteitä, kuten sinun ja dokumentaatio, että tilanteita ei ole paljon viesti. Voin täysin hyväksyä, että se on ehkä totta, mutta etsin muutakin kuin väitettä. Selityksesi toisesta osasta auttaa minua sanomalla, että virheilmoituksen näyttäminen ei ehkä ole väärin, mutta se voi olla parempi tapa. Kiitos vastauksestasi! - person KobeJohn; 17.10.2011
comment
Mitä syitä voit ajatella, miksi sivua ei löydy? (1) linkki oli rikki, (2) käyttäjä on kirjoittanut sen väärin (katso #1). Jos on muita syitä, kuten virheellisiä tietoja syötettiin, sen ei pitäisi olla 404. Käytä muita HTTP-vastauskoodeja osoittaaksesi, että vastaus epäonnistui. 409: ristiriitaiset tiedot, 403: kielletty jne. - person Matthew Schinckel; 17.10.2011
comment
Ymmärrän kyllä. Tätä olen itsekin ihmetellyt. Samoin kuin kommenttini Matthewlle, oletetaan, että URL-osoitteen suodatin/järjestysparametrit näyttävät olevan virheellisesti muotoiltu. Eikö se ole 404? Ehkä haukun väärää puuta. Katsoin kaikki HTTP-vastaukset läpi, enkä löytänyt sopivampaa. - person KobeJohn; 19.10.2011
comment
Palauttaisin 409: Conflict. (Tai tavallinen 400: Virhe). Jos hahmonnat vain HTML-koodia, palauttaisit 200, mutta sivun tiedot osoittavat, että kyseessä on virhe. (Suurin osa verkkosovellusohjelmoinnistani on API-pohjaista, jossa 4xx-sarjan vastauksilla voi olla ja on runko.) - person Matthew Schinckel; 19.10.2011

arrow_upward
1
arrow_downward

Jos tietosi saapuvat, kuten:

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

Sitten teet väärin :)

Tämän jälkeen sinun on käytettävä säännöllisiä lausekkeita käsiteltävien tietojen jäsentämiseen.

Jotkut ihmiset, kun he kohtaavat ongelman, ajattelevat "Tiedän, käytän säännöllisiä lausekkeita". Nyt heillä on kaksi ongelmaa.

(Zawinski, 1997)

Käytä sen sijaan GET-parametreja, kuten pastylegs ehdottaa.

Vielä parempi, käytä django-lomakekäsittelyä ja:

  • luo lomake, jolla on vahvistussäännöt
  • renderöi syöttösivu kyseiseltä lomakkeelta
  • jäsentää käyttäjän syöttämäsi lomakkeen avulla
  • näytä tiedot, jos lomake oli kelvollinen, muuten näyttää vahvistusvirheet käyttäjän syötteen rinnalla

Voit tehdä tämän GET-pyynnöillä tai POST-pyynnöillä. POST:n etuna on "puhtaat" URL-osoitteet ja pidempi tietorunko. GET tarkoittaa, että URL-osoitteet voidaan lisätä kirjanmerkkeihin.

Tämä kaikki johtuu siitä, että käytetään kehyksen oikeita osia oikeisiin tehtäviin. URL-reititys käyttää säännöllisiä lausekkeita selvittääkseen, mikä URL-osoite osuu mihin tahansa näkymään. Mitä yksinkertaisempia URL-malleja teet, sitä helpompi niitä on ylläpitää. Käyttäjän syötteet tulee käsitellä lomakkeilla.

person Matthew Schinckel    schedule 17.10.2011
comment
Huomioi tehdä se väärin. Selityksenä... luettuaan RESTful-verkkokehityksen ja Matrix URI:t (1996) kirjoittajan Tim Berners-Lee Sain inspiraation kirjoittaa järjestelmän matriisi-URI:ien käsittelemiseksi puolipistemuodossa. Se on joustavampi järjestelmä kuin kysely, mutta sitä ei vain ole toteutettu kehyksissä, joten kyllä ​​se vaatii jäsentämistä :) - person KobeJohn; 19.10.2011
comment
Mitä tulee parametrien sisältöön, ne eivät sinänsä ole käyttäjän syötteitä. Ne ovat suodattimia ja tilausohjeita sivulla näkyville tietoluetteloille. Käyttäjä voi muokata niitä, jos käytettävissä on joitain säätimiä. Oletetaan siis, että tässä tilanteessa muunnan käyttämään kyselymerkkijonoa ja GET-parametreja, mikä on oikea tapa toimia esim. virheelliset suodatin/järjestysparametrit kyselymerkkijonossa? - person KobeJohn; 19.10.2011
comment
Minun kantani on, että jos käyttäjä valitsee asioita, ja tämä vaikuttaa saapuvaan dataan, se on käyttäjän syöte. Sovelluksesi asiakaspuoli vahvistaa sen todennäköisesti jonkin verran, mutta palvelimen pitäisi silti vahvistaa se. Mitä tulee tilaamiseen: jos käytät kartoituksia (ja käytät lomaketta), se häviää. Virheelliset tiedot: -› renderöi lomake uudelleen näyttäen, kuinka tiedot ovat ristiriidassa. - person Matthew Schinckel; 19.10.2011
comment
Selvyyden vuoksi: älä jää kiinni siihen tosiasiaan, että lomake koostuu yleensä HTML-kentistä. Jos voit, aseta sivusi säätimet päivittämään piilotetut kentät lomake-elementissä, joka sitten julkaistaan. - person Matthew Schinckel; 19.10.2011

arrow_upward
1
arrow_downward

Luulen, että sinun on vaikea ymmärtää tätä, koska yrität sekoittaa kahta eri asiaa.

Ensinnäkin on kysymys siitä, löytyikö varsinainen sivu vai ei.
Toiseksi on kysymys siitä, olivatko annetut parametrit kelvollisia vai eivät.

Joten jos (osittainen) url on:

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

Jos sivua /whatever/default ei löydy, sinulle (pitäisi) näyttää "404 Page not found"-tyyppinen virheilmoitus. Tässä tapauksessa et voi kertoa, olivatko annetut parametrit tai arvot oikein. Pyydettyä sivua ei ole olemassa, joten et tiedä mille sivulle parametrit on tarkoitettu. Et voi edes olettaa, että oikea domain name määritettiin. Saattaa olla monia mielivaltaisia ​​verkkotunnuksia, URL-osoitteita ja sivuja, joilla parametrit ovat kelvollisia, ja monia muita, joilla parametrit ovat virheellisiä.

Jos sivu /whatever/default löytyy, niin:
Jos väärien parametrien määrittäminen saattaa saada sivun lataamaan/uudelleenohjaamaan olemattoman sivun, tämän sivun tulisi estää se. Tarvittaessa kyseisen sivun tulisi olla toimitettujen parametrien vahvistaminen ja asianmukaisten toimien suorittaminen sekä asianmukaisten viestien näyttäminen.

person Kevin Fegan    schedule 24.02.2013