Django 2.1 - Built-in Views

अंतर्निहित दृश्य




django

अंतर्निहित दृश्य

Django के कई बिल्ट-इन व्यूज़ को राइटिंग व्यूज़ के साथ-साथ डॉक्यूमेंटेशन में कहीं और डॉक्यूमेंट में लिखा गया है।

विकास में फाइलें सेवित करना

static.serve(request, path, document_root, show_indexes=False)

आपकी परियोजना की स्थिर संपत्ति के अलावा अन्य फाइलें भी हो सकती हैं, जो सुविधा के लिए, आप चाहते हैं कि आपके लिए स्थानीय विकास में Django की सेवा हो। serve() दृश्य का उपयोग आपके द्वारा दी गई किसी भी निर्देशिका की सेवा के लिए किया जा सकता है। (यह दृश्य उत्पादन के उपयोग के लिए कठोर नहीं है और इसका उपयोग केवल एक विकास सहायता के रूप में किया जाना चाहिए; आपको वास्तविक फ्रंट-एंड वेब सर्वर का उपयोग करके उत्पादन में इन फ़ाइलों की सेवा करनी चाहिए)।

सबसे अधिक संभावित उदाहरण MEDIA_ROOT में उपयोगकर्ता द्वारा अपलोड की गई सामग्री है। django.contrib.staticfiles स्थिर संपत्तियों के लिए अभिप्रेत है और इसमें उपयोगकर्ता द्वारा अपलोड की गई फ़ाइलों के लिए कोई अंतर्निहित हैंडलिंग नहीं है, लेकिन आप Django को अपने URLconf के लिए कुछ इस तरह से जोड़कर अपने MEDIA_ROOT सेवा कर सकते हैं:

from django.conf import settings
from django.urls import re_path
from django.views.static import serve

# ... the rest of your URLconf goes here ...

if settings.DEBUG:
    urlpatterns += [
        re_path(r'^media/(?P<path>.*)$', serve, {
            'document_root': settings.MEDIA_ROOT,
        }),
    ]

ध्यान दें, स्निपेट मानता है कि आपके MEDIA_URL का मूल्य '/media/' । यह URLconf और (आवश्यक) document_root पैरामीटर से पथ में गुजरने वाले serve() दृश्य को कॉल करेगा।

चूंकि यह इस URL पैटर्न को परिभाषित करने के लिए थोड़ा बोझिल हो सकता है, Django जहाज एक छोटे URL सहायक फ़ंक्शन static() जो कि MEDIA_URL जैसे उपसर्ग और दृश्य के लिए एक बिंदीदार पथ, जैसे 'django.views.static.serve' । किसी अन्य फ़ंक्शन पैरामीटर को पारदर्शी रूप से दृश्य में पास किया जाएगा।

त्रुटि दृश्य

Django HTTP त्रुटियों को संभालने के लिए डिफ़ॉल्ट रूप से कुछ विचारों के साथ आता है। अपने स्वयं के कस्टम दृश्यों के साथ इन्हें ओवरराइड करने के लिए, त्रुटि विचारों को अनुकूलित करना देखें।

404 (पृष्ठ नहीं मिला) दृश्य

defaults.page_not_found(request, exception, template_name='404.html')

जब आप एक दृश्य के भीतर से Http404 हैं, तो Django 404 त्रुटियों से निपटने के लिए समर्पित एक विशेष दृश्य लोड करता है। डिफ़ॉल्ट रूप से, यह दृश्य django.views.defaults.page_not_found() , जो या तो एक बहुत ही सरल "नहीं मिला" संदेश का उत्पादन करता है या यदि आपने इसे अपने टेम्पलेट टेम्पलेट निर्देशिका में बनाया है तो यह टेम्पलेट 404.html को लोड और रेंडर करता है।

डिफ़ॉल्ट 404 दृश्य टेम्पलेट के दो चर पास करेगा: request_path , जो URL है जिसके परिणामस्वरूप त्रुटि हुई, और exception , जो दृश्य को ट्रिगर करने वाले अपवाद का एक उपयोगी प्रतिनिधित्व है (उदाहरण के लिए किसी विशिष्ट Http404 उदाहरण के लिए दिया गया कोई संदेश शामिल है) )।

404 विचारों पर ध्यान देने योग्य तीन बातें:

  • 404 दृश्य को भी कहा जाता है, यदि Django URLconf में प्रत्येक नियमित अभिव्यक्ति की जाँच करने के बाद एक मैच नहीं पाता है।
  • 404 दृश्य एक RequestContext और आपके टेम्पलेट संदर्भ प्रोसेसर (जैसे MEDIA_URL ) द्वारा आपूर्ति की गई चर तक पहुंच होगी।
  • यदि DEBUG True (आपकी सेटिंग मॉड्यूल में) पर सेट है, तो आपका 404 दृश्य कभी भी उपयोग नहीं किया जाएगा, और आपके URLconf को कुछ डिबग जानकारी के साथ प्रदर्शित किया जाएगा।

500 (सर्वर त्रुटि) दृश्य

defaults.server_error(request, template_name='500.html')

इसी तरह, Django व्यू कोड में रनटाइम त्रुटियों के मामले में विशेष-केस व्यवहार को निष्पादित करता है। यदि एक अपवाद के परिणामस्वरूप कोई दृश्य दिखाई देता है, तो Django, डिफ़ॉल्ट रूप से, दृश्य django.views.defaults.server_error कॉल django.views.defaults.server_error , जो या तो एक बहुत ही सरल "सर्वर त्रुटि" संदेश का उत्पादन करता है या यदि आप इसे चाहते हैं तो यह टेम्पलेट 500.html को लोड और प्रस्तुत करता है अपने रूट टेम्पलेट निर्देशिका।

डिफ़ॉल्ट 500 दृश्य 500.html टेम्पलेट के लिए कोई चर नहीं 500.html है और अतिरिक्त त्रुटियों की संभावना को कम करने के लिए एक खाली Context साथ प्रदान किया जाता है।

यदि DEBUG True (आपकी सेटिंग मॉड्यूल में) पर सेट है, तो आपका 500 दृश्य कभी भी उपयोग नहीं किया जाएगा, और ट्रेसबैक को कुछ डिबग जानकारी के साथ प्रदर्शित किया जाएगा।

403 (HTTP निषिद्ध) दृश्य

defaults.permission_denied(request, exception, template_name='403.html')

404 और 500 विचारों के समान नस में, Django के पास 403 निषिद्ध त्रुटियों को संभालने के लिए एक दृश्य है। यदि कोई दृश्य 403 अपवाद में होता है, तो Django डिफ़ॉल्ट रूप से, django.views.defaults.permission_denied के दृश्य को कॉल django.views.defaults.permission_denied

यह दृश्य आपके रूट टेम्प्लेट डायरेक्टरी में टेम्प्लेट 403.html को लोड और रेंडर करता है, या यदि यह फाइल मौजूद नहीं है, तो इसके बजाय RFC 7231 # सेक्शन-6.5.3 (HTTP 1.1 विनिर्देशन) के अनुसार "403 फॉरबिडन" टेक्स्ट परोसता है। टेम्पलेट संदर्भ में exception शामिल exception , जो दृश्य को ट्रिगर करने वाले अपवाद का स्ट्रिंग प्रतिनिधित्व है।

django.views.defaults.permission_denied की PermissionDenied एक PermissionDenied अपवाद द्वारा PermissionDenied है। किसी दृश्य में पहुंच को अस्वीकार करने के लिए आप इस तरह कोड का उपयोग कर सकते हैं:

from django.core.exceptions import PermissionDenied

def edit(request, pk):
    if not request.user.is_staff:
        raise PermissionDenied
    # ...

400 (बुरा अनुरोध) दृश्य

defaults.bad_request(request, exception, template_name='400.html')

जब Django में एक SuspiciousOperation विकल्प उठाया जाता है, तो इसे Django के एक घटक द्वारा संभाला जा सकता है (उदाहरण के लिए सत्र डेटा रीसेट करना)। यदि विशेष रूप से नियंत्रित नहीं किया जाता है, तो Django एक सर्वर त्रुटि के बजाय वर्तमान अनुरोध को 'खराब अनुरोध' पर विचार करेगा।

django.views.defaults.bad_request , अन्यथा अन्यथा server_error दृश्य के समान है, लेकिन स्थिति कोड 400 के साथ लौटता है, यह दर्शाता है कि त्रुटि स्थिति क्लाइंट ऑपरेशन का परिणाम थी। डिफ़ॉल्ट रूप से, दृश्य को ट्रिगर करने वाले अपवाद से संबंधित कुछ भी टेम्पलेट संदर्भ में पारित नहीं किया जाता है, क्योंकि अपवाद संदेश में फ़ाइल सिस्टम पथ जैसी संवेदनशील जानकारी हो सकती है।

bad_request दृश्य भी केवल तब उपयोग किए जाते हैं जब DEBUG False