Niyə Django standart 404 görünüşü ilə səhv mesajlarını ötürmür?

(Kontekst: Mən hələ Django və veb inkişafı üçün çox yeniyəm.)

1) Kimsə aşağıdakı ifadənin səbəbini izah edə bilərmi? Bu S/ A necə bununla məşğul olmaq sualına cavab verdi, lakin bunun niyə yaxşı/pis fikir ola biləcəyini yox.

Sənədlər bildirir ki, "səhifə_not_found" Görünüş Veb tətbiqlərinin 99%-i üçün kifayət etməlidir, lakin onu ləğv etmək istəyirsinizsə, URLconf-da handler404-ü təyin edə bilərsiniz".

Yəni, page_not_found görünüşü yalnız tələb olunan URL-ə keçir və istisna qaldırarkən verdiyiniz hər hansı mesaja məhəl qoymur. Mənə elə gəlir ki, defolt olaraq 404.html şablonuna faydalı məsləhətlər vermək üçün seçimin olması hamı üçün yaxşı olardı.

2) Aşağıdakı vəziyyət üçün faydalı mesajlar ötürmək üçün hazırda fərdi görünüş yaradıram. Etməməyim üçün bir səbəb varmı?

Mən matris URL-lərindən istifadə edirəm, ona görə də əsas resurs normal iyerarxik URL-dir, ondan sonra əsas formatda matris seçimləri: ;filter_type1=item:value,item:value;filter_type2=item:value...

Beləliklə, səhv etmədən əvvəl təhlilin nə qədər uzağa getdiyinə əsaslanaraq faydalı mesajlar təqdim etmək olduqca asandır. Aşağıdakı kimi bir mesaj ötürmək mənə faydalı görünür:

  • "İcazə verilən filter_növləri bunlardır: type1, type2, type3." və ya
  • "A filter_type üçün icazə verilən elementlər bunlardır: element1, element2, element3."

Əgər bu izahı başqa yerdə buraxmışamsa, üzr istəyirəm. Mən baxdım və mən lakin heç bir cavab almadı.


django
person KobeJohn    schedule 16.10.2011    source mənbə
comment
Deyəsən suala yalnız dolayı yolla cavab verilib. Ancaq indiyə qədər verilən cavablara əsasən, cavabın belə olduğunu güman etməliyəm: 404-də səhv mesajına ehtiyacınız varsa, səhv edirsiniz.   -  person KobeJohn    schedule 20.10.2011

Cavablar (3)


arrow_upward
1
arrow_downward

Sualın nə olduğundan əmin deyiləm. page_not_found görünüşü defolt olaraq əsasdır, çünki orada Səhifənin niyə tapılmadığını izah etməyiniz lazım olan bir çox vəziyyətlər deyil.

Güman edirəm ki, "matris variantları" dedikdə siz URL/GET parametrlərini nəzərdə tutursunuz:

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

Yanlış parametr kombinasiyasını daxil edərlərsə, 404 atmaq əvəzinə, niyə defolt olaraq əsas url/şablonda (http://domain.com/page/) "Seçim1 yalnız x,y,z ola bilər" deyən xəta mesajı olmasın. ". Bu yolla onlara tanış bir səhifə təqdim olunur və 404 səhifədən geri qayıtmadan öz seçimlərini yenidən sınaya bilərlər (və bunun niyə işləmədiyi o qədər də çaşdırıcı deyil).

Bunu asanlıqla yerinə yetirmək üçün djanqonun mesajlaşma çərçivəsindən istifadə edə bilərsiniz (mən keçmişdə belə olub). Görünüşdə parametrləri yoxlayarkən şablona xəta mesajı göndərin.

person Timmy O'Mahony    schedule 16.10.2011
comment
...defolt olaraq əsasdır, çünki səhifənin niyə tapılmadığını izah etməli olduğunuz o qədər də çox vəziyyət yoxdur... Mən yalnız sizin və sənədlər kimi iddiaları görmüşəm. mesaj. Bəlkə də bunun doğru olduğunu tamamilə qəbul edə bilərəm, amma mən iddiadan daha çox şey axtarıram. İkinci hissədəki izahınız səhv mesajı göstərməyin səhv olmaya biləcəyini, lakin bunu etmək üçün daha yaxşı bir yol ola biləcəyini söyləməklə mənə kömək edir. Cavabınız üçün təşəkkür edirik! - person KobeJohn; 17.10.2011
comment
Səhifənin tapılmamasının hansı səbəbləri barədə düşünə bilərsiniz. (1) keçid pozuldu, (2) istifadəçi onu səhv yazdı (bax №1). Etibarsız məlumatların daxil edilməsi kimi başqa səbəblər varsa, o, 404 olmamalıdır. Cavabın uğursuz olduğunu göstərmək üçün digər HTTP cavab kodlarından istifadə edin. 409: ziddiyyətli məlumatlar, 403: qadağandır və s. - person Matthew Schinckel; 17.10.2011
comment
Kifayət qədər ədalətli. Bu barədə özüm də maraqlanmışam. Metyuya verdiyim şərhə bənzər, deyək ki, URL-dəki filtr/sifariş parametrləri səhv formalaşdırılıb. 404 deyilmi? Ola bilsin ki, mən səhv ağaca hürürəm. Mən bütün HTTP cavablarına baxdım və daha uyğun olanı tapmadım. - person KobeJohn; 19.10.2011
comment
Mən 409: Münaqişə qaytarardım. (Və ya düz 400: Səhv). Əgər siz sadəcə HTML təqdim edirsinizsə, onda siz 200 qaytararsınız, lakin səhifə məlumatları göstərir ki, xəta var. (Mənim veb-tətbiq proqramlaşdırmamın çoxu API əsaslıdır, burada 4xx seriyalı cavabların bədəni ola bilər və ola bilər.) - person Matthew Schinckel; 19.10.2011

arrow_upward
1
arrow_downward

Məlumatlarınız aşağıdakı kimi gəlirsə:

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

Onda səhv edirsən :)

Daha sonra emal ediləcək məlumatları təhlil etmək üçün müntəzəm ifadələrdən istifadə etməlisiniz.

Bəzi insanlar problemlə qarşılaşanda “Bilirəm, müntəzəm ifadələr işlədəcəm” deyə düşünür. İndi onların iki problemi var.

(Zavinski, 1997)

Bunun əvəzinə, pastylegs təklif etdiyi kimi, GET parametrlərindən istifadə edin.

Daha yaxşısı, django formasının idarə edilməsindən istifadə edin və:

  • doğrulama qaydaları olan forma yaradın
  • həmin formadan daxiletmə səhifəsini göstərin
  • formadan istifadə edərək istifadəçi daxiletməsini təhlil edin
  • forma etibarlıdırsa, məlumatları göstərin, əks halda istifadəçi daxiletməsi ilə yanaşı doğrulama səhvlərini göstərin

Bunu GET sorğuları və ya POST sorğuları ilə edə bilərsiniz. POST 'təmiz' URL-lərə və daha uzun məlumat orqanına sahib olmaq üstünlüyünə malikdir. GET o deməkdir ki, url-lər əlfəcin edilə bilər.

Bütün bunlardan irəli gələn şey çərçivənin düzgün hissələrini düzgün tapşırıqlar üçün istifadə etməkdir. URL marşrutlaşdırma hansı URL-nin hansı görünüşə çatdığını öyrənmək üçün müntəzəm ifadələrdən istifadə edir. URL nümunələrini nə qədər sadə etsəniz, onlara qulluq etmək bir o qədər asan olacaq. İstifadəçi daxiletməsi formalarla idarə olunmalıdır.

person Matthew Schinckel    schedule 17.10.2011
comment
Səhv etdiyinə diqqət yetirildi. Sadəcə izah etmək üçün... RESTful veb inkişafı və Matrix URI-lərini (1996) oxuduqdan sonra Tim Berners-Li Məni nöqtəli vergül formatı ilə matris URI-ləri idarə etmək üçün bir sistem yazmaqdan ilham aldım. Bu, sorğudan daha çevik bir sistemdir, lakin o, sadəcə çərçivələrdə tətbiq edilmir, ona görə də bəli, təhlilə ehtiyacı var :) - person KobeJohn; 19.10.2011
comment
Parametrlərin məzmununa gəldikdə, onlar öz-özlüyündə istifadəçi girişi deyil. Onlar səhifədə görünəcək məlumatların siyahıları üçün filtrlər və sifariş istiqamətləridir. Bəzi nəzarətlər təmin olunarsa, onlar istifadəçi tərəfindən dəyişdirilə bilər. Beləliklə, bu vəziyyətdə, deyək ki, mən sorğu sətirindən və GET parametrlərindən istifadə etməyə çevrilirəm, məsələn, getmək üçün doğru yol nədir? sorğu sətirində səhv formalaşmış filtr/sifariş parametrləri? - person KobeJohn; 19.10.2011
comment
Mənim mövqeyim budur ki, əgər istifadəçi hər şeyi seçirsə və bu, daxil olan məlumatlara təsir edirsə, deməli bu, istifadəçi girişidir. Çox güman ki, o, tətbiqinizin müştəri tərəfi tərəfindən müəyyən qədər təsdiqlənib, lakin yenə də server tərəfindən təsdiqlənməlidir. Sifarişə gəlincə: əgər siz xəritələrdən istifadə etsəniz (və formadan istifadə edəcəksinizsə), bu, yox olur. Yanlış məlumat: -› verilənlərin necə zidd olduğunu göstərən formanı yenidən göstərin. - person Matthew Schinckel; 19.10.2011
comment
Daha aydın etmək üçün: formanın adətən HTML sahələri olduğuna əsaslanmayın. Mümkünsə, səhifə nəzarətlərini ‹form› elementində gizli sahələri yeniləməyə məcbur edin, sonra yerləşdiriləcək. - person Matthew Schinckel; 19.10.2011

arrow_upward
1
arrow_downward

Düşünürəm ki, bunu anlamaqda çətinlik çəkdiyiniz səbəb 2 fərqli məsələni qarışdırmağa çalışmanızdır.

Birincisi, faktiki səhifənin tapılıb tapılmaması məsələsidir.
İkincisi, verilən parametrlərin etibarlı olub-olmaması məsələsidir.

Beləliklə, əgər (qismən) url:

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

Əgər /whatever/default səhifəsi tapılmadısa, sizə "404 Page not found" tipli xəta mesajı göstəriləcək. Bu halda, verilən parametrlərin və ya dəyərlərin düzgün olub-olmadığını deyə bilməzsiniz. Tələb olunan səhifə mövcud deyil, ona görə də parametrlərin hansı səhifə üçün nəzərdə tutulduğunu bilmirsiniz. Siz hətta düzgün domain name-nin göstərildiyini güman edə bilməzsiniz. Parametrlərin etibarlı olduğu bir çox ixtiyari domenlər, URL-lər və səhifələr və parametrlərin etibarsız olduğu bir çox başqaları ola bilər.

Əgər /whatever/default səhifəsi tapılırsa, onda:
Səhv parametrlərin göstərilməsi həmin səhifənin mövcud olmayan səhifəni yükləməsinə/yönləndirməsinə səbəb ola bilərsə, o zaman bunun qarşısı həmin səhifə tərəfindən alınmalıdır. Lazım gələrsə, təqdim olunan parametrləri təsdiqləmək və müvafiq tədbirlər görmək və müvafiq mesajları göstərmək həmin səhifəyə qədər olmalıdır.

person Kevin Fegan    schedule 24.02.2013