Django डीफॉल्ट 404 दृश्यासह त्रुटी संदेश का देत नाही?

(संदर्भ: मी अजूनही जॅंगो आणि वेब डेव्हलपमेंटसाठी नवीन आहे.)

1) कोणीतरी खालील विधानाचे कारण स्पष्ट करू शकेल का? हा प्रश्न/ A ने कसे या प्रश्नाचे उत्तर दिले, परंतु ती चांगली/वाईट कल्पना का असू शकते असे नाही.

दस्तऐवज असे सांगतात, "The page_not_found 99% वेब ऍप्लिकेशन्ससाठी व्ह्यू पुरेसा असावा, परंतु तुम्हाला ते ओव्हरराइड करायचे असल्यास, तुम्ही तुमच्या URLconf मध्ये हँडलर404 निर्दिष्ट करू शकता.

म्हणजेच, page_not_found दृश्य फक्त विनंती केलेल्या URL वर जाते आणि अपवाद वाढवताना तुम्ही दिलेल्या कोणत्याही संदेशाकडे दुर्लक्ष करते. मला असे वाटते की 404.html टेम्पलेटला डीफॉल्टनुसार उपयुक्त संकेत प्रदान करण्यासाठी पर्याय असणे प्रत्येकासाठी चांगले असेल.

2) मी सध्या एक सानुकूल दृश्य बनवत आहे जेणेकरुन मी खालील परिस्थितीसाठी उपयुक्त संदेश पाठवू शकेन. मी करू नये असे काही कारण आहे का?

मी मॅट्रिक्स URL वापरत आहे त्यामुळे बेस रिसोर्स ही एक सामान्य श्रेणीबद्ध URL आहे ज्यानंतर मॅट्रिक्स पर्याय या मूलभूत स्वरूपातील आहेत: ;filter_type1=item:value,item:value;filter_type2=item:value...

त्यामुळे एरर येण्यापूर्वी पार्सिंग किती लांब आहे यावर आधारित उपयुक्त संदेश प्रदान करणे खूप सोपे आहे. खालीलप्रमाणे संदेश पाठवणे मला उपयुक्त वाटते:

  • "अनुमत फिल्टर_प्रकार आहेत: type1, type2, type3." किंवा
  • "filter_type a साठी अनुमत आयटम आहेत: item1, item2, item3."

माझे हे स्पष्टीकरण इतरत्र चुकले असल्यास क्षमस्व. मी पाहिले आहे आणि मी वर google django-users पण कोणतेही उत्तर मिळाले नाही.


django
person KobeJohn    schedule 16.10.2011    source स्रोत
comment
असे वाटते की प्रश्नाचे उत्तर अप्रत्यक्षपणे दिले गेले आहे. तथापि आतापर्यंतच्या उत्तरांवर आधारित, मी असे गृहीत धरले पाहिजे की उत्तर आहे: जर तुम्हाला 404 मध्ये त्रुटी संदेश हवा असेल तर तुम्ही ते चुकीचे करत आहात.   -  person KobeJohn    schedule 20.10.2011

उत्तरे (3)


arrow_upward
1
arrow_downward

मला खरोखर प्रश्न काय आहे याची खात्री नाही. page_not_found दृश्य मूलभूत आहे कारण तेथे अशा अनेक परिस्थिती नाहीत ज्यात तुम्हाला हे स्पष्ट करणे आवश्यक आहे की पृष्ठ का सापडले नाही त्याशिवाय ते सापडले नाही.

मी 'मॅट्रिक्स पर्याय' द्वारे गृहीत धरतो तुम्हाला URL/GET पॅरामीटर्स म्हणायचे आहे जसे:

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

जर त्यांनी पॅरामीटरचे चुकीचे संयोजन एंटर केले तर 404 फेकण्याऐवजी, "Option1 फक्त x,y,z असू शकते" अशा त्रुटी संदेशासह बेस url/template (http://domain.com/page/) वर डीफॉल्ट का नाही? " अशा प्रकारे ते परिचित पृष्ठासह सादर केले जातात आणि 404 पृष्ठावरून परत नेव्हिगेट न करता त्यांच्या निवडीचा पुन्हा प्रयत्न करू शकतात (आणि ते का कार्य करत नाही हे इतके गोंधळात टाकणारे नाही).

हे सहज साध्य करण्यासाठी तुम्ही django चे मेसेजिंग फ्रेमवर्क वापरू शकता (मी भूतकाळात असे केले आहे). जेव्हा तुम्ही दृश्यातील पॅरामीटर्स तपासत असाल तेव्हा टेम्पलेटवर त्रुटी संदेश द्या.

person Timmy O'Mahony    schedule 16.10.2011
comment
...डिफॉल्टनुसार मूलभूत आहे कारण पृष्ठ का सापडले नाही याचे स्पष्टीकरण देण्याची गरज असलेल्या अनेक परिस्थिती नाहीत... मी फक्त तुमचे आणि दस्तऐवज यांसारखे विधान पाहिले आहे की अशा अनेक परिस्थिती नाहीत संदेश कदाचित ते खरे आहे हे मी पूर्णपणे स्वीकारू शकतो, परंतु मी प्रतिपादनापेक्षा अधिक शोधत आहे. दुसर्‍या भागावरील तुमचे स्पष्टीकरण मला असे सांगून मदत करते की त्रुटी संदेश दर्शविणे चुकीचे असू शकत नाही परंतु ते करण्याचा आणखी चांगला मार्ग असू शकतो. तुमच्या उत्तराबद्दल धन्यवाद! - person KobeJohn; 17.10.2011
comment
एखादे पान का सापडले नाही याची कोणती कारणे तुम्ही विचार करू शकता. (1) एक दुवा तुटला होता, (2) वापरकर्त्याने तो चुकीचा टाइप केला आहे (#1 पहा). अवैध डेटा एंटर केल्यासारखी इतर कोणतीही कारणे असल्यास, ती 404 नसावी. प्रतिसाद अयशस्वी झाल्याचे दर्शविण्यासाठी इतर HTTP प्रतिसाद कोड वापरा. 409: परस्परविरोधी डेटा, 403: निषिद्ध इ. - person Matthew Schinckel; 17.10.2011
comment
पुरेसा गोरा. मला स्वतःला याबद्दल आश्चर्य वाटले आहे. मॅथ्यूच्या माझ्या टिप्पणीप्रमाणेच, URL मधील फिल्टर/ऑर्डर पॅरामीटर्स विकृत असल्याचे समजू या. ते 404 नाही का? कदाचित मी चुकीचे झाड भुंकत आहे. मी सर्व HTTP प्रतिसाद पाहिले आणि मला अधिक योग्य आढळले नाही. - person KobeJohn; 19.10.2011
comment
मी 409: संघर्ष परत करेन. (किंवा एक साधा 400: त्रुटी). तथापि, तुम्ही फक्त HTML रेंडर करत असल्यास, तुम्ही 200 परत कराल, परंतु पृष्ठ डेटामध्ये त्रुटी असल्याचे दर्शविते. (माझे बहुतेक वेब-अॅप्लिकेशन प्रोग्रामिंग API आधारित आहे, जेथे 4xx मालिका प्रतिसादांना मुख्य भाग असू शकतो आणि करू शकतो.) - person Matthew Schinckel; 19.10.2011

arrow_upward
1
arrow_downward

तुमचा डेटा येत असल्यास:

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

मग तुम्ही चुकीचे करत आहात :)

त्यानंतर प्रक्रिया करायच्या डेटाचे विश्लेषण करण्यासाठी तुम्हाला रेग्युलर एक्सप्रेशन वापरण्याची आवश्यकता आहे.

काही लोक, एखाद्या समस्येचा सामना करताना, "मला माहित आहे, मी नियमित अभिव्यक्ती वापरेन" असे वाटते. आता त्यांना दोन समस्या आहेत.

(झाविन्स्की, 1997)

त्याऐवजी, पेस्टाइलग्सने सुचवल्याप्रमाणे, GET पॅरामीटर्स वापरा.

आणखी चांगले, जॅंगो फॉर्म हाताळणीचा वापर करा आणि:

  • एक फॉर्म तयार करा, ज्यामध्ये प्रमाणीकरण नियम आहेत
  • त्या फॉर्ममधून इनपुट पृष्ठ रेंडर करा
  • फॉर्म वापरून वापरकर्ता इनपुट पार्स करा
  • फॉर्म वैध असल्यास डेटा प्रदर्शित करा, अन्यथा वापरकर्ता इनपुटसह प्रमाणीकरण त्रुटी प्रदर्शित करा

तुम्ही हे GET विनंत्या किंवा पोस्ट विनंत्यांसह करू शकता. POST ला 'क्लीन' urls आणि डेटा बॉडी लांब असण्याचा फायदा आहे. GET चा अर्थ असा आहे की url बुकमार्क केली जाऊ शकतात.

हे सर्व खाली येते ते म्हणजे योग्य कार्यांसाठी फ्रेमवर्कचे योग्य भाग वापरणे. कोणती URL कोणती दृश्य हिट करते हे शोधण्यासाठी URL राउटिंग नियमित अभिव्यक्ती वापरते. तुम्ही url पॅटर्न जितके सोपे कराल तितके ते राखणे सोपे होईल. वापरकर्ता इनपुट फॉर्मद्वारे हाताळले जावे.

person Matthew Schinckel    schedule 17.10.2011
comment
ते चुकीचे केल्याने घेतलेला मुद्दा. फक्त स्पष्ट करण्यासाठी... RESTful वेब विकास आणि Matrix URIs (1996) वाचल्यानंतर टिम बर्नर्स-ली मला सेमीकोलन फॉरमॅटसह मॅट्रिक्स यूआरआय हाताळण्यासाठी एक प्रणाली लिहिण्यास प्रेरित केले. ही क्वेरीपेक्षा अधिक लवचिक प्रणाली आहे, परंतु ती फक्त फ्रेमवर्कमध्ये लागू केलेली नाही म्हणून होय ​​त्याचे विश्लेषण करणे आवश्यक आहे :) - person KobeJohn; 19.10.2011
comment
पॅरामीटर्सच्या सामग्रीसाठी, ते प्रति से वापरकर्ता इनपुट नाहीत. ते पृष्ठावर दिसणार्‍या डेटाच्या सूचीसाठी फिल्टर आणि ऑर्डरिंग दिशानिर्देश आहेत. काही नियंत्रणे प्रदान केली असल्यास वापरकर्त्याद्वारे ते सुधारित केले जाऊ शकतात. तर या परिस्थितीत, समजा मी क्वेरी स्ट्रिंग आणि GET पॅरामीटर्स वापरून रूपांतरित करतो, यासाठी जाण्याचा योग्य मार्ग कोणता आहे उदा. क्वेरी स्ट्रिंगमध्ये विकृत फिल्टर/ऑर्डर पॅरामीटर्स? - person KobeJohn; 19.10.2011
comment
माझी स्थिती अशी आहे की जर वापरकर्त्याने काही गोष्टी निवडल्या आणि नंतर त्याचा परिणाम येणार्‍या डेटावर झाला, तर तो वापरकर्ता इनपुट आहे. हे कदाचित तुमच्या अर्जाच्या क्लायंट-साइडद्वारे काही प्रमाणात प्रमाणित केले जाईल, परंतु तरीही सर्व्हरद्वारे प्रमाणित केले जावे. ऑर्डर करण्यासाठी: तुम्ही मॅपिंग वापरल्यास (आणि फॉर्म वापरण्यासाठी, तुम्ही कराल), ते निघून जाईल. चुकीचा डेटा: -> डेटा कसा विरोधाभास होतो हे दर्शविते फॉर्म पुन्हा रेंडर करा. - person Matthew Schinckel; 19.10.2011
comment
हे स्पष्ट करण्यासाठी: फॉर्म सामान्यत: HTML फील्ड असतो यावर स्थिर होऊ नका. जर तुम्हाला शक्य असेल तर, तुमचे पृष्ठ नियंत्रण ‹फॉर्म› घटकामध्ये लपवलेले फील्ड अपडेट करा, जे नंतर पोस्ट केले जाईल. - person Matthew Schinckel; 19.10.2011

arrow_upward
1
arrow_downward

मला असे वाटते की तुम्हाला हे समजण्यात अडचण येण्याचे कारण आहे, तुम्ही 2 भिन्न मुद्दे मिसळण्याचा प्रयत्न करत आहात.

प्रथम, वास्तविक पृष्ठ सापडले की नाही हा मुद्दा आहे.
दुसरा, प्रदान केलेले पॅरामीटर्स वैध होते की नाही हा मुद्दा आहे.

तर, जर (आंशिक) url असेल:

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

जर पृष्ठ /whatever/default सापडले नाही, तर तुम्हाला "404 Page not found" प्रकारचा त्रुटी संदेश दाखवला जाईल. या प्रकरणात, प्रदान केलेले पॅरामीटर्स किंवा मूल्ये योग्य असल्यास तुम्ही सांगू शकत नाही. विनंती केलेले पृष्ठ अस्तित्वात नाही, त्यामुळे पॅरामीटर्स कोणत्या पृष्ठासाठी आहेत हे आपल्याला माहित नाही. योग्य domain name निर्दिष्ट केले होते असे तुम्ही गृहीतही धरू शकत नाही. पॅरामीटर्स वैध असलेल्या अनेक अनियंत्रित डोमेन, url आणि पृष्ठे असू शकतात आणि इतर अनेक जिथे पॅरामीटर्स अवैध आहेत.

जर पृष्ठ /whatever/default सापडले, तर:
चुकीचे पॅरामीटर्स निर्दिष्ट केल्यामुळे ते पृष्ठ अस्तित्वात नसलेले पृष्ठ लोड/पुनर्निर्देशित करू शकते, तर त्या पृष्ठाद्वारे ते प्रतिबंधित केले जावे. आवश्यक असल्यास, प्रदान केलेल्या पॅरामीटर्सचे प्रमाणीकरण करणे आणि योग्य कृती करणे आणि योग्य संदेश दर्शविणे हे त्या पृष्ठापर्यंत असावे.

person Kevin Fegan    schedule 24.02.2013