Django 2.1 - Working with forms

रूपों के साथ काम करना




django

रूपों के साथ काम करना

इस दस्तावेज़ के बारे में

यह दस्तावेज़ वेब रूपों की मूल बातें और कैसे उन्हें Django में संभाला जाता है, के लिए एक परिचय प्रदान करता है। प्रपत्र API के विशिष्ट क्षेत्रों पर अधिक विस्तृत नज़र के लिए, प्रपत्र API , प्रपत्र फ़ील्ड और फ़ॉर्म और फ़ील्ड सत्यापन देखें

जब तक आप ऐसी वेबसाइट और एप्लिकेशन बनाने की योजना नहीं बना रहे हैं जो कुछ भी नहीं करते हैं लेकिन सामग्री प्रकाशित करते हैं, और अपने आगंतुकों से इनपुट स्वीकार नहीं करते हैं, तो आपको रूपों को समझने और उपयोग करने की आवश्यकता है।

Django आपको साइट आगंतुकों से इनपुट स्वीकार करने के लिए फॉर्म बनाने में मदद करने के लिए टूल और लाइब्रेरी की एक श्रृंखला प्रदान करता है, और फिर प्रोसेस करके इनपुट पर प्रतिक्रिया देता है।

HTML रूपों

HTML में, एक फॉर्म <form>...</form> अंदर तत्वों का एक संग्रह होता है, जो आगंतुक को पाठ में प्रवेश करने, विकल्पों का चयन करने, वस्तुओं या नियंत्रणों में हेरफेर करने, आदि करने की अनुमति देता है, और फिर उस जानकारी को वापस भेजता है। सर्वर के लिए।

इनमें से कुछ फ़ॉर्म इंटरफ़ेस तत्व - टेक्स्ट इनपुट या चेकबॉक्स - काफी सरल हैं और HTML में ही बनाए गए हैं। अन्य बहुत अधिक जटिल हैं; एक इंटरफ़ेस जो एक तिथि पिकर को पॉप अप करता है या आपको एक स्लाइडर को स्थानांतरित करने या नियंत्रणों को हेरफेर करने की अनुमति देता है, आमतौर पर इन प्रभावों को प्राप्त करने के लिए जावास्क्रिप्ट और सीएसएस के साथ-साथ HTML फॉर्म <input> तत्वों का उपयोग करेगा।

साथ ही इसके <input> तत्व, एक फॉर्म में दो चीजें निर्दिष्ट करनी चाहिए:

  • कहाँ : वह URL जिससे उपयोगकर्ता के इनपुट के संगत डेटा वापस किया जाना चाहिए
  • कैसे : HTTP विधि द्वारा डेटा लौटाया जाना चाहिए

एक उदाहरण के रूप में, Django एडमिन के लिए लॉगिन फॉर्म में कई <input> एलिमेंट्स होते हैं: यूज़रनेम के लिए type="text" में से एक, type="password" लिए type="password" में से एक, और एक type="submit" लिए। "लॉग इन" बटन। इसमें कुछ छिपे हुए टेक्स्ट फ़ील्ड भी शामिल हैं जिन्हें उपयोगकर्ता नहीं देखता है, जो Django यह निर्धारित करने के लिए उपयोग करता है कि आगे क्या करना है।

यह ब्राउज़र को यह भी बताता है कि फ़ॉर्म डेटा को <form> की action विशेषता - /admin/ - में निर्दिष्ट URL पर भेजा जाना चाहिए और इसे method विशेषता - post द्वारा निर्दिष्ट HTTP तंत्र का उपयोग करके भेजा जाना चाहिए।

जब <input type="submit" value="Log in"> तत्व चालू हो जाता है, तो डेटा /admin/ को वापस कर दिया जाता है।

GET और POST

फॉर्म के साथ काम करते समय GET और POST केवल HTTP तरीके हैं।

Django का लॉगिन फ़ॉर्म POST विधि का उपयोग करके लौटाया गया है, जिसमें ब्राउज़र प्रपत्र डेटा को बंडल करता है, इसे ट्रांसमिशन के लिए एन्कोड करता है, इसे सर्वर पर भेजता है, और फिर अपनी प्रतिक्रिया वापस प्राप्त करता है।

इसके विपरीत, GET डेटा को एक स्ट्रिंग में बंडल करता है, और एक URL की रचना करने के लिए इसका उपयोग करता है। URL में वह पता होता है जहाँ डेटा भेजा जाना चाहिए, साथ ही डेटा कुंजियाँ और मान भी। यदि आप Django दस्तावेज़ में एक खोज करते हैं, तो आप इसे कार्रवाई में देख सकते हैं, जो https://docs.djangoproject.com/search/?q=forms&release=1 फ़ॉर्म का एक URL उत्पन्न करेगा।

GET और POST का उपयोग आमतौर पर विभिन्न उद्देश्यों के लिए किया जाता है।

किसी भी अनुरोध को सिस्टम की स्थिति को बदलने के लिए इस्तेमाल किया जा सकता है - उदाहरण के लिए, एक अनुरोध जो डेटाबेस में बदलाव करता है - POST उपयोग करना चाहिए। GET का उपयोग केवल उन अनुरोधों के लिए किया जाना चाहिए जो सिस्टम की स्थिति को प्रभावित नहीं करते हैं।

पासवर्ड के लिए GET भी अनुपयुक्त होगा, क्योंकि पासवर्ड URL में दिखाई देगा, और इस प्रकार, ब्राउज़र इतिहास और सर्वर लॉग में भी, सभी सादे पाठ में। न तो यह बड़ी मात्रा में डेटा के लिए उपयुक्त होगा, न ही बाइनरी डेटा के लिए, जैसे कि एक छवि। एक वेब एप्लिकेशन जो व्यवस्थापक प्रपत्रों के लिए GET अनुरोधों का उपयोग करता है, एक सुरक्षा जोखिम है: किसी हमलावर के लिए सिस्टम के संवेदनशील भागों तक पहुंच प्राप्त करने के लिए किसी प्रपत्र के अनुरोध की नकल करना आसान हो सकता है। POST , Django के CSRF सुरक्षा जैसे अन्य सुरक्षा के साथ मिलकर उपयोग पर अधिक नियंत्रण प्रदान करता है।

दूसरी ओर, GET वेब खोज फ़ॉर्म जैसी चीज़ों के लिए उपयुक्त है, क्योंकि जो URL एक GET अनुरोध का प्रतिनिधित्व करते हैं, उन्हें आसानी से बुकमार्क, साझा या पुनः सबमिट किया जा सकता है।

रूपों में Django की भूमिका

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

Django के फॉर्म की कार्यक्षमता इस कार्य के विशाल भागों को सरल और स्वचालित कर सकती है, और अधिकांश प्रोग्रामर की तुलना में इसे अधिक सुरक्षित रूप से कर सकते हैं जो कोड उन्होंने स्वयं लिखा था।

Django रूपों में शामिल काम के तीन अलग-अलग हिस्सों को संभालता है:

  • इसे तैयार करने के लिए डेटा तैयार करना और उसका पुनर्गठन करना
  • डेटा के लिए HTML फॉर्म बनाना
  • क्लाइंट से फॉर्म और डेटा प्राप्त करना और संसाधित करना

कोड लिखना संभव है जो यह सब मैन्युअल रूप से करता है, लेकिन Django आप सभी के लिए इसका ख्याल रख सकता है।

Django में प्रपत्र

हमने संक्षिप्त रूप में HTML रूपों का वर्णन किया है, लेकिन एक HTML <form> आवश्यक मशीनरी का केवल एक हिस्सा है।

किसी वेब एप्लिकेशन के संदर्भ में, 'फॉर्म' उस HTML <form> , या इसे बनाने वाले Django Form को संदर्भित कर सकता है, या इसे सबमिट किए जाने पर, या एंड-टू-एंड वर्किंग कलेक्शन में लौटाए गए संरचित डेटा में। इन भागों के।

द Django Form क्लास

घटकों के इस प्रणाली के दिल में Django के Form वर्ग है। जिस तरह से एक Django मॉडल किसी ऑब्जेक्ट की तार्किक संरचना, उसके व्यवहार और उसके भागों का जिस तरह से हमारे लिए प्रतिनिधित्व करता है, उसका वर्णन करता है, एक Form क्लास एक Form वर्णन करता है और यह निर्धारित करता है कि यह कैसे काम करता है और प्रकट होता है।

इसी तरह से एक मॉडल वर्ग के फ़ील्ड डेटाबेस फ़ील्ड पर मैप करते हैं, एक फॉर्म क्लास के फ़ील्ड मैप से HTML फॉर्म <input> तत्व। (एक ModelForm एक मॉडल वर्ग के फ़ील्ड को HTML फ़ॉर्म <input> तत्वों के माध्यम से Form माध्यम से मैप करता है; यह वही है जो Django के आधार पर है।)

एक फॉर्म के क्षेत्र स्वयं कक्षाएं हैं; वे प्रपत्र डेटा प्रबंधित करते हैं और फ़ॉर्म सबमिट किए जाने पर सत्यापन करते हैं। एक DateField और एक FileField बहुत भिन्न प्रकार के डेटा को DateField और इसके साथ अलग-अलग चीजें करनी होती हैं।

एक प्रपत्र फ़ील्ड को ब्राउज़र में एक उपयोगकर्ता को HTML "विजेट" के रूप में दर्शाया जाता है - उपयोगकर्ता इंटरफ़ेस मशीनरी का एक टुकड़ा। प्रत्येक फ़ील्ड प्रकार में एक उपयुक्त डिफ़ॉल्ट विजेट वर्ग होता है , लेकिन इन्हें आवश्यकतानुसार ओवरराइड किया जा सकता है।

त्वरित करना, प्रसंस्करण, और रूपों को प्रस्तुत करना

जब Django में एक वस्तु प्रदान, हम आम तौर पर:

  1. दृश्य में इसे पकड़ें (डेटाबेस से प्राप्त करें, उदाहरण के लिए)
  2. इसे टेम्प्लेट संदर्भ में पास करें
  3. टेम्पलेट वैरिएबल का उपयोग करके इसे HTML मार्कअप में विस्तारित करें

किसी टेम्प्लेट में किसी प्रपत्र को रेंडर करने में लगभग उसी तरह का काम होता है जैसे किसी अन्य प्रकार की वस्तु को प्रस्तुत करना, लेकिन कुछ प्रमुख अंतर हैं।

एक मॉडल उदाहरण के मामले में जिसमें कोई डेटा नहीं था, यह शायद ही कभी होगा यदि किसी टेम्पलेट में इसके साथ कुछ भी करना उपयोगी हो। दूसरी ओर, यह एक अनपेक्षित रूप को प्रस्तुत करने के लिए सही अर्थ है - यही हम तब करते हैं जब हम चाहते हैं कि उपयोगकर्ता इसे आबाद करे।

इसलिए जब हम किसी दृश्य में एक मॉडल उदाहरण को संभालते हैं, तो हम आम तौर पर इसे डेटाबेस से पुनर्प्राप्त करते हैं। जब हम एक फॉर्म के साथ काम कर रहे होते हैं तो हम आम तौर पर इसे देखने में तुरंत कर देते हैं।

जब हम किसी फॉर्म को तत्काल भेजते हैं, तो हम इसे खाली छोड़ने या इसे पूर्व-आबाद करने का विकल्प चुन सकते हैं, उदाहरण के लिए:

  • सहेजे गए मॉडल उदाहरण से डेटा (संपादन के लिए व्यवस्थापक प्रपत्र के मामले में)
  • डेटा जो हम अन्य स्रोतों से टकराए हैं
  • पिछले HTML फ़ॉर्म सबमिशन से प्राप्त डेटा

इन मामलों में से अंतिम सबसे दिलचस्प है, क्योंकि यह वही है जो उपयोगकर्ताओं के लिए न केवल एक वेबसाइट को पढ़ना संभव बनाता है, बल्कि इसके बारे में जानकारी भी वापस भेजना है।

एक रूप का निर्माण

जिस काम को करने की जरूरत है

मान लीजिए कि आप उपयोगकर्ता का नाम प्राप्त करने के लिए, अपनी वेबसाइट पर एक साधारण फ़ॉर्म बनाना चाहते हैं। आपको अपने टेम्पलेट में कुछ इस तरह की आवश्यकता होगी:

<form action="/your-name/" method="post">
    <label for="your_name">Your name: </label>
    <input id="your_name" type="text" name="your_name" value="{{ current_name }}">
    <input type="submit" value="OK">
</form>

यह ब्राउज़र को POST विधि का उपयोग करके URL /your-name/ लिए प्रपत्र डेटा वापस करने के लिए कहता है। यह "आपका नाम:" और "ओके" के रूप में चिह्नित एक बटन के साथ एक टेक्स्ट फ़ील्ड प्रदर्शित करेगा। यदि टेम्प्लेट के संदर्भ में एक current_name वैरिएबल है, जिसका उपयोग your_name फ़ील्ड को प्री-फिल करने के लिए किया जाएगा।

आपको एक दृश्य की आवश्यकता होगी जो HTML फॉर्म वाले टेम्पलेट को प्रस्तुत करता है, और जो current_name फ़ील्ड को उचित रूप में आपूर्ति कर सकता है।

जब फॉर्म सबमिट किया जाता है, तो सर्वर पर भेजे जाने वाले POST अनुरोध में फॉर्म डेटा होगा।

अब आपको उस /your-name/ URL से संबंधित एक दृश्य की भी आवश्यकता होगी जो अनुरोध में उपयुक्त कुंजी / मूल्य जोड़े को ढूंढेगा, और फिर उन्हें संसाधित करेगा।

यह एक बहुत ही सरल रूप है। व्यवहार में, एक फॉर्म में दर्जनों या सैकड़ों फ़ील्ड शामिल हो सकते हैं, जिनमें से कई को पूर्व-आबाद करने की आवश्यकता हो सकती है, और हम ऑपरेशन के समापन से पहले उपयोगकर्ता को कई बार एडिट-सबमिट चक्र के माध्यम से काम करने की उम्मीद कर सकते हैं।

हमें ब्राउज़र जमा करने के लिए कुछ सत्यापन की आवश्यकता हो सकती है, भले ही फ़ॉर्म सबमिट होने से पहले हो; हम बहुत अधिक जटिल क्षेत्रों का उपयोग करना चाह सकते हैं, जो उपयोगकर्ता को कैलेंडर इत्यादि की तारीखों जैसे काम करने की अनुमति देता है।

इस समय यह Django प्राप्त करने के लिए हमारे लिए यह सबसे काम करना बहुत आसान है।

Django में एक फार्म का निर्माण

Form क्लास

हम पहले से ही जानते हैं कि हम क्या चाहते हैं कि हमारा HTML फॉर्म कैसा दिखे। Django में इसके लिए हमारा शुरुआती बिंदु यह है:

from django import forms

class NameForm(forms.Form):
    your_name = forms.CharField(label='Your name', max_length=100)

यह एक एकल फ़ील्ड ( your_name ) के साथ एक Form क्लास को परिभाषित करता है। हमने फ़ील्ड में एक मानव-अनुकूल लेबल लागू किया है, जो <label> में दिखाई देगा, जब इसे रेंडर किया जाएगा (हालांकि इस मामले में, हमने जो label निर्दिष्ट किया है वह वास्तव में वही है जो स्वचालित रूप से उत्पन्न होगा यदि हमने इसे छोड़ दिया था) ।

फ़ील्ड की अधिकतम स्वीकार्य लंबाई को max_length द्वारा परिभाषित किया गया है। यह दो काम करता है। यह HTML <input> पर एक maxlength="100" डालता है (इसलिए ब्राउज़र को उपयोगकर्ता को पहली जगह में वर्णों की संख्या से अधिक दर्ज करने से रोकना चाहिए)। इसका यह भी अर्थ है कि जब Django ब्राउज़र से फॉर्म वापस प्राप्त करता है, तो यह डेटा की लंबाई को मान्य करेगा।

एक Form is_valid() में एक is_valid() विधि है, जो अपने सभी क्षेत्रों के लिए सत्यापन रूटीन चलाता है। जब इस विधि को कहा जाता है, यदि सभी क्षेत्रों में मान्य डेटा है, तो यह होगा:

  • True
  • प्रपत्र के डेटा को उसकी cleaned_data विशेषता में रखें।

संपूर्ण रूप, जब पहली बार प्रस्तुत किया जाता है, जैसा दिखेगा:

<label for="your_name">Your name: </label>
<input id="your_name" type="text" name="your_name" maxlength="100" required>

ध्यान दें कि इसमें <form> टैग या सबमिट बटन शामिल नहीं है। हमें उन्हें स्वयं टेम्पलेट में प्रदान करना होगा।

दृश्य

एक Django वेबसाइट पर भेजे गए फॉर्म डेटा को एक दृश्य द्वारा संसाधित किया जाता है, आम तौर पर एक ही दृश्य जो प्रपत्र प्रकाशित करता है। यह हमें उसी तर्क में से कुछ का पुन: उपयोग करने की अनुमति देता है।

उस फ़ॉर्म को संभालने के लिए जिसे हमें उस URL के लिए दृश्य में तत्काल भेजना है जहाँ हम इसे प्रकाशित करना चाहते हैं:

from django.http import HttpResponseRedirect
from django.shortcuts import render

from .forms import NameForm

def get_name(request):
    # if this is a POST request we need to process the form data
    if request.method == 'POST':
        # create a form instance and populate it with data from the request:
        form = NameForm(request.POST)
        # check whether it's valid:
        if form.is_valid():
            # process the data in form.cleaned_data as required
            # ...
            # redirect to a new URL:
            return HttpResponseRedirect('/thanks/')

    # if a GET (or any other method) we'll create a blank form
    else:
        form = NameForm()

    return render(request, 'name.html', {'form': form})

यदि हम एक GET अनुरोध के साथ इस दृश्य पर पहुंचते हैं, तो यह एक रिक्त प्रपत्र उदाहरण बनाएगा और इसे टेम्पलेट संदर्भ में प्रदान किया जाएगा। यह वह है जो हम URL पर पहली बार आने की उम्मीद कर सकते हैं।

यदि फॉर्म POST अनुरोध का उपयोग करके सबमिट किया जाता है, तो दृश्य एक बार फिर से एक फॉर्म इंस्टेंस बनाएगा और उसे अनुरोध के डेटा के साथ पॉप्युलेट करेगा: form = NameForm(request.POST) इसे " form = NameForm(request.POST) से डेटा form = NameForm(request.POST) " कहा जाता है (यह अब है) एक बाध्य रूप)।

हम फॉर्म का is_valid() विधि कहते हैं; यदि यह True नहीं है, तो हम प्रपत्र के साथ टेम्पलेट पर वापस जाते हैं। इस बार फ़ॉर्म अब खाली नहीं है ( अनबाउंड ) इसलिए HTML फॉर्म पहले से सबमिट किए गए डेटा के साथ पॉपुलेट किया जाएगा, जहां इसे संपादित किया जा सकता है और आवश्यकतानुसार इसे सही किया जा सकता है।

यदि is_valid() True , तो हम अब इसके cleaned_data विशेषता में सभी मान्य प्रपत्र डेटा को ढूँढने में सक्षम होंगे। डेटाबेस को अपडेट करने या ब्राउज़र को HTTP रीडायरेक्ट भेजने से पहले अन्य प्रोसेसिंग करने के लिए इस डेटा का उपयोग कर सकते हैं।

नमूना

हमें अपने name.html टेम्पलेट में बहुत कुछ करने की आवश्यकता नहीं है। सबसे सरल उदाहरण है:

<form action="/your-name/" method="post">
    {% csrf_token %}
    {{ form }}
    <input type="submit" value="Submit">
</form>

सभी प्रकार के फ़ील्ड और उनकी विशेषताओं को Django की टेम्पलेट भाषा द्वारा उस {{ form }} से HTML मार्कअप में अनपैक किया जाएगा।

फॉर्म्स की सुरक्षा के लिए फॉर्म और क्रॉस साइट अनुरोध

क्रॉस साइट रिक्वेस्ट फोर्सेज के खिलाफ एक आसानी से उपयोग होने वाली सुरक्षा के साथ Django के जहाज। CSRF सुरक्षा के साथ POST माध्यम से एक फॉर्म सबमिट करते समय सक्षम होना चाहिए कि आप पूर्ववर्ती उदाहरण में csrf_token टेम्पलेट टैग का उपयोग करें। हालाँकि, चूंकि CSRF संरक्षण सीधे टेम्प्लेट में प्रपत्रों से बंधा नहीं है, इसलिए यह टैग इस दस्तावेज़ में निम्नलिखित उदाहरणों से छोड़ा गया है।

HTML5 इनपुट प्रकार और ब्राउज़र सत्यापन

यदि आपके फ़ॉर्म में URLField , एक EmailField या कोई पूर्णांक फ़ील्ड प्रकार शामिल है, तो Django url , email और number HTML5 इनपुट प्रकारों का उपयोग करेगा। डिफ़ॉल्ट रूप से, ब्राउज़र इन क्षेत्रों पर अपना सत्यापन लागू कर सकते हैं, जो कि Django के सत्यापन की तुलना में सख्त हो सकता है। यदि आप इस व्यवहार को अक्षम करना चाहते हैं, तो form टैग पर novalidate विशेषता सेट करें, या novalidate जैसे फ़ील्ड पर एक अलग विजेट निर्दिष्ट करें।

अब हमारे पास एक कामकाजी वेब फॉर्म है, जिसे एक Django Form द्वारा वर्णित किया गया है, जिसे एक दृश्य द्वारा संसाधित किया गया है, और एक HTML <form> रूप में प्रस्तुत किया गया है।

बस आपको शुरुआत करने की आवश्यकता है, लेकिन रूपों की रूपरेखा आपकी उंगलियों पर बहुत अधिक डालती है। एक बार जब आप ऊपर वर्णित प्रक्रिया की मूल बातें समझ लेते हैं, तो आपको फॉर्म सिस्टम की अन्य विशेषताओं को समझने के लिए तैयार रहना चाहिए और अंतर्निहित मशीनरी के बारे में थोड़ा और जानने के लिए तैयार होना चाहिए।

Django फॉर्म कक्षाओं के बारे में अधिक

सभी फॉर्म क्लासेस को Form या ModelForm उपवर्ग के रूप में बनाया जाता है। आप ModelForm को Form उपवर्ग के रूप में सोच सकते हैं। Form और ModelForm वास्तव में एक (निजी) BaseForm वर्ग से सामान्य कार्यक्षमता प्राप्त करते हैं, लेकिन यह कार्यान्वयन विस्तार शायद ही कभी महत्वपूर्ण है।

मॉडल और फॉर्म

वास्तव में यदि आपका फॉर्म Django मॉडल को सीधे जोड़ने या संपादित करने के लिए उपयोग किया जा रहा है, तो एक ModelForm आपको समय, प्रयास और कोड का एक बड़ा सौदा बचा सकता है, क्योंकि यह उपयुक्त फ़ील्ड और उनकी विशेषताओं के साथ एक फॉर्म का निर्माण करेगा। एक Model वर्ग से।

बाउंड और अनबाउंड फॉर्म इंस्टेंस

बाउंड और अनबाउंड फॉर्म के बीच का अंतर महत्वपूर्ण है:

  • एक अनबाउंड फॉर्म के पास कोई डेटा नहीं है। जब उपयोगकर्ता को प्रदान किया जाता है, तो यह खाली हो जाएगा या इसमें डिफ़ॉल्ट मान होंगे।
  • एक बाउंड फ़ॉर्म ने डेटा जमा किया है, और इसलिए यह बताने के लिए उपयोग किया जा सकता है कि क्या डेटा मान्य है। यदि एक अमान्य बाध्य प्रपत्र प्रदान किया गया है, तो यह इनलाइन त्रुटि संदेशों को शामिल कर सकता है जिसमें उपयोगकर्ता को यह बताना होगा कि कौन सा डेटा सही है।

प्रपत्र की is_bound विशेषता आपको बताएगी कि किसी प्रपत्र में डेटा है या नहीं।

खेतों पर अधिक

उपरोक्त हमारे न्यूनतम उदाहरण से अधिक उपयोगी रूप पर विचार करें, जिसे हम एक निजी वेबसाइट पर "मुझसे संपर्क करें" कार्यक्षमता को लागू करने के लिए उपयोग कर सकते हैं:

from django import forms

class ContactForm(forms.Form):
    subject = forms.CharField(max_length=100)
    message = forms.CharField(widget=forms.Textarea)
    sender = forms.EmailField()
    cc_myself = forms.BooleanField(required=False)

हमारे पहले के फॉर्म में एक एकल फ़ील्ड, your_name , एक CharField । इस मामले में, हमारे फॉर्म के चार क्षेत्र हैं: subject , message , sender और cc_myself CharField , EmailField और BooleanField उपलब्ध क्षेत्र प्रकारों में से केवल तीन हैं; फ़ॉर्म फ़ील्ड में एक पूरी सूची मिल सकती है।

विजेट

प्रत्येक प्रपत्र फ़ील्ड में एक समान विजेट वर्ग होता है , जो बदले में एक HTML फॉर्म विजेट से मेल खाता है, जैसे <input type="text">

ज्यादातर मामलों में, फ़ील्ड में एक समझदार डिफ़ॉल्ट विजेट होगा। उदाहरण के लिए, डिफ़ॉल्ट रूप से, एक CharField में एक TextInput विजेट होगा, जो HTML में एक <input type="text"> का उत्पादन करता है। यदि आपको इसके बजाय <textarea> आवश्यकता है, तो आप अपने प्रपत्र फ़ील्ड को परिभाषित करते समय उपयुक्त विजेट निर्दिष्ट करेंगे, जैसा कि हमने message फ़ील्ड के लिए किया है।

कार्यक्षेत्र का डाटा

एक फॉर्म के साथ जो भी डेटा सबमिट किया गया है, एक बार is_valid() (और is_valid() True वापस आ गया है is_valid() को कॉल करके सफलतापूर्वक is_valid() किया गया है, form.cleaned_data फॉर्म डेटा form.cleaned_data डिक्शनरी में होगा। यह डेटा आपके लिए अच्छी तरह से पायथन प्रकारों में परिवर्तित हो गया होगा।

ध्यान दें

आप इस बिंदु पर request.POST से सीधे अनप्लग किए गए डेटा तक पहुँच सकते हैं। लेकिन मान्य डेटा बेहतर है।

ऊपर दिए गए संपर्क फ़ॉर्म उदाहरण में, cc_myself एक बूलियन मान होगा। इसी तरह, IntegerField और FloatField जैसे क्षेत्र एक पायथन int मूल्यों को परिवर्तित करते हैं और क्रमशः float हैं।

यहां बताया गया है कि इस प्रपत्र को संभालने वाले दृश्य में प्रपत्र डेटा को कैसे संसाधित किया जा सकता है:

from django.core.mail import send_mail

if form.is_valid():
    subject = form.cleaned_data['subject']
    message = form.cleaned_data['message']
    sender = form.cleaned_data['sender']
    cc_myself = form.cleaned_data['cc_myself']

    recipients = ['[email protected]']
    if cc_myself:
        recipients.append(sender)

    send_mail(subject, message, sender, recipients)
    return HttpResponseRedirect('/thanks/')

टिप

Django से ईमेल भेजने पर अधिक जानकारी के लिए, ईमेल भेजना देखें।

कुछ फ़ील्ड प्रकारों को कुछ अतिरिक्त हैंडलिंग की आवश्यकता होती है। उदाहरण के लिए, किसी प्रपत्र का उपयोग करके अपलोड की गई फ़ाइलों को अलग तरीके से हैंडल करने की आवश्यकता होती है (उन्हें request.FILES के बजाय request.FILES से पुनर्प्राप्त किया जा सकता है)। अपने प्रपत्र के साथ फ़ाइल अपलोड को कैसे संभालना है, इसके विवरण के लिए, बाइंड की गई फ़ाइलों को फ़ॉर्म में देखें

फॉर्म टेम्पलेट के साथ काम करना

आपको अपने फॉर्म को टेम्प्लेट में लाने के लिए फॉर्म इंस्टेंस को फॉर्म के संदर्भ में रखना है। इसलिए यदि आपके फॉर्म को संदर्भ में form कहा जाता है, तो {{ form }} इसके <label> और <input> तत्वों को उचित {{ form }} से प्रस्तुत करेगा।

प्रपत्र रेंडरिंग विकल्प

अतिरिक्त रूप टेम्पलेट फर्नीचर

यह मत भूलो कि एक फॉर्म के आउटपुट में आसपास का <form> टैग, या फॉर्म का submit कंट्रोल शामिल नहीं है। आपको ये स्वयं प्रदान करने होंगे।

<label> / <input> जोड़े के लिए हालांकि अन्य आउटपुट विकल्प हैं:

  • {{ form.as_table }} उन्हें <tr> टैग में लिपटे टेबल कोशिकाओं के रूप में प्रस्तुत करेगा
  • {{ form.as_p }} उन्हें <p> टैग में लपेटकर प्रस्तुत करेगा
  • {{ form.as_ul }} उन्हें <li> टैग में लपेटकर प्रस्तुत करेगा

ध्यान दें कि आपको आसपास <table> या <ul> तत्व प्रदान करने होंगे।

हमारे ContactForm उदाहरण के लिए {{ form.as_p }} का आउटपुट यहां दिया गया है:

<p><label for="id_subject">Subject:</label>
    <input id="id_subject" type="text" name="subject" maxlength="100" required></p>
<p><label for="id_message">Message:</label>
    <textarea name="message" id="id_message" required></textarea></p>
<p><label for="id_sender">Sender:</label>
    <input type="email" name="sender" id="id_sender" required></p>
<p><label for="id_cc_myself">Cc myself:</label>
    <input type="checkbox" name="cc_myself" id="id_cc_myself"></p>

ध्यान दें कि प्रत्येक प्रपत्र फ़ील्ड में id_<field-name> लिए एक आईडी विशेषता सेट है, जिसे साथ लेबल टैग द्वारा संदर्भित किया गया है। यह सुनिश्चित करने में महत्वपूर्ण है कि प्रपत्र सहायक तकनीक जैसे स्क्रीन रीडर सॉफ़्टवेयर तक पहुंच योग्य हों। आप उस तरीके को भी कस्टमाइज़ कर सकते हैं जिसमें लेबल और आईडी जेनरेट होते हैं

इस पर अधिक के लिए HTML के रूप में आउटपुट स्वरूप देखें।

खेतों को मैन्युअल रूप से रेंडर करना

हमें Django को फॉर्म के फ़ील्ड को अनपैक करने की आवश्यकता नहीं है; हम इसे मैन्युअल रूप से कर सकते हैं यदि हम चाहें (उदाहरण के लिए, हमें खेतों को फिर से व्यवस्थित करने की अनुमति देते हैं)। प्रत्येक फ़ील्ड {{ form.name_of_field }} का उपयोग करते हुए फ़ॉर्म की विशेषता के रूप में उपलब्ध है, और एक Django टेम्पलेट में उचित रूप से प्रदान किया जाएगा। उदाहरण के लिए:

{{ form.non_field_errors }}
<div class="fieldWrapper">
    {{ form.subject.errors }}
    <label for="{{ form.subject.id_for_label }}">Email subject:</label>
    {{ form.subject }}
</div>
<div class="fieldWrapper">
    {{ form.message.errors }}
    <label for="{{ form.message.id_for_label }}">Your message:</label>
    {{ form.message }}
</div>
<div class="fieldWrapper">
    {{ form.sender.errors }}
    <label for="{{ form.sender.id_for_label }}">Your email address:</label>
    {{ form.sender }}
</div>
<div class="fieldWrapper">
    {{ form.cc_myself.errors }}
    <label for="{{ form.cc_myself.id_for_label }}">CC yourself?</label>
    {{ form.cc_myself }}
</div>

पूरा <label> तत्व भी label_tag() का उपयोग करके उत्पन्न किया जा सकता है। उदाहरण के लिए:

<div class="fieldWrapper">
    {{ form.subject.errors }}
    {{ form.subject.label_tag }}
    {{ form.subject }}
</div>

प्रपत्र त्रुटि संदेश रेंडर करना

बेशक, इस लचीलेपन की कीमत अधिक काम है। अब तक हमें फॉर्म की त्रुटियों को प्रदर्शित करने के तरीके के बारे में चिंता करने की ज़रूरत नहीं है, क्योंकि यह हमारे लिए ध्यान रखा गया है। इस उदाहरण में हमें यह सुनिश्चित करना होगा कि हम प्रत्येक क्षेत्र के लिए किसी भी त्रुटि और समग्र रूप से किसी भी त्रुटि के लिए ध्यान रखें। नोट {{ form.non_field_errors }} फॉर्म के शीर्ष पर और प्रत्येक फ़ील्ड पर त्रुटियों के लिए टेम्पलेट लुकअप।

{{ form.name_of_field.errors }} का उपयोग करते हुए, प्रपत्र त्रुटियों की एक सूची प्रदर्शित करता है, जो एक {{ form.name_of_field.errors }} सूची के रूप में प्रदान की जाती है। ऐसा लग सकता है:

<ul class="errorlist">
    <li>Sender is required.</li>
</ul>

सूची में सीएसएस वर्ग की errorlist सूची है, जिससे आप इसकी उपस्थिति को देख सकते हैं। यदि आप त्रुटियों के प्रदर्शन को और अधिक अनुकूलित करना चाहते हैं, तो आप उन पर लूपिंग करके ऐसा कर सकते हैं:

{% if form.subject.errors %}
    <ol>
    {% for error in form.subject.errors %}
        <li><strong>{{ error|escape }}</strong></li>
    {% endfor %}
    </ol>
{% endif %}

गैर-फ़ील्ड त्रुटियां (और / या छिपी हुई फ़ील्ड त्रुटियां जो प्रपत्र के शीर्ष पर रेंडर की जाती हैं, जब form.as_p() ) जैसे सहायकों का उपयोग करके उन्हें फ़ील्ड-विशिष्ट त्रुटियों से अलग करने में मदद करने के लिए nonfield एक अतिरिक्त वर्ग के साथ प्रदान किया जाएगा। उदाहरण के लिए, {{ form.non_field_errors }} जैसा दिखेगा:

<ul class="errorlist nonfield">
    <li>Generic validation error</li>
</ul>

टेम्प्लेट में प्रपत्र विशेषताओं के साथ त्रुटियों, स्टाइलिंग और कार्य करने के लिए फ़ॉर्म API देखें।

फार्म के खेतों पर लूपिंग

यदि आप अपने प्रत्येक फॉर्म फ़ील्ड के लिए एक ही एचटीएमएल का उपयोग कर रहे हैं, तो आप प्रत्येक {% for %} फ़ील्ड फ़ॉर {% for %} लूप का उपयोग करके डुप्लिकेट कोड को कम कर सकते हैं।

{% for field in form %}
    <div class="fieldWrapper">
        {{ field.errors }}
        {{ field.label_tag }} {{ field }}
        {% if field.help_text %}
        <p class="help">{{ field.help_text|safe }}</p>
        {% endif %}
    </div>
{% endfor %}

{{ field }} पर उपयोगी विशेषताओं में शामिल हैं:

{{ field.label }}
फ़ील्ड का लेबल, जैसे Email address
{{ field.label_tag }}

फ़ील्ड का लेबल उपयुक्त HTML <label> टैग में लिपटा है। इसमें फॉर्म का label_suffix । उदाहरण के लिए, डिफ़ॉल्ट label_suffix एक बृहदान्त्र है:

<label for="id_email">Email address:</label>
{{ field.id_for_label }}
इस फ़ील्ड के लिए उपयोग की जाने वाली ID (ऊपर उदाहरण में id_email )। यदि आप मैन्युअल रूप से लेबल का निर्माण कर रहे हैं, तो आप इसे label_tag बदले में उपयोग करना चाह सकते हैं। यह उपयोगी भी है, उदाहरण के लिए, यदि आपके पास कुछ इनलाइन जावास्क्रिप्ट हैं और क्षेत्र की आईडी को हार्डकोड करने से बचना चाहते हैं।
{{ field.value }}
क्षेत्र का मूल्य। जैसे कोई [email protected]
{{ field.html_name }}
फ़ील्ड का नाम जिसका उपयोग इनपुट तत्व के नाम फ़ील्ड में किया जाएगा। यह प्रपत्र उपसर्ग को ध्यान में रखता है, यदि इसे सेट किया गया है।
{{ field.help_text }}
कोई भी मदद पाठ जो क्षेत्र के साथ संबद्ध किया गया है।
{{ field.errors }}
आउटपुट <ul class="errorlist"> इस क्षेत्र के अनुरूप कोई भी सत्यापन त्रुटि है। आप {% for error in field.errors %} लूप के लिए त्रुटियों की प्रस्तुति को अनुकूलित कर सकते हैं। इस स्थिति में, लूप में प्रत्येक ऑब्जेक्ट त्रुटि संदेश वाला एक साधारण स्ट्रिंग है।
{{ field.is_hidden }}
यह विशेषता True यदि प्रपत्र फ़ील्ड एक छुपा फ़ील्ड है और अन्यथा False है। यह खासतौर पर टेम्प्लेट वैरिएबल के रूप में उपयोगी नहीं है, लेकिन सशर्त परीक्षणों में उपयोगी हो सकता है जैसे:
{% if field.is_hidden %}
   {# Do something special #}
{% endif %}
{{ field.field }}
प्रपत्र श्रेणी से Field आवृत्ति जो यह BoundField लपेटता है। आप इसका उपयोग Field विशेषताओं, जैसे {{ char_field.field.max_length }} तक पहुंचने के लिए कर सकते हैं।

यह भी देखें

विशेषताओं और विधियों की पूरी सूची के लिए, BoundField देखें।

छिपे हुए और दृश्यमान क्षेत्रों पर लूपिंग

यदि आप मैन्युअल रूप से टेम्पलेट में एक फ़ॉर्म भर रहे हैं, जैसा कि Django के डिफ़ॉल्ट फ़ॉर्म लेआउट पर निर्भर है, तो आप गैर-छिपे हुए फ़ील्ड से अलग तरह से <input type="hidden"> फ़ील्ड का इलाज करना चाह सकते हैं। उदाहरण के लिए, क्योंकि छिपे हुए फ़ील्ड कुछ भी प्रदर्शित नहीं करते हैं, त्रुटि संदेश "बगल में" फ़ील्ड आपके उपयोगकर्ताओं के लिए भ्रम पैदा कर सकता है - इसलिए उन फ़ील्ड के लिए त्रुटियों को अलग तरीके से नियंत्रित किया जाना चाहिए।

Django एक फॉर्म पर दो तरीके प्रदान करता है जो आपको छिपे हुए और दृश्यमान क्षेत्रों पर स्वतंत्र रूप से लूप करने की अनुमति देता है: hidden_fields() और visible_fields() । यहाँ एक पुराने उदाहरण का संशोधन है जो इन दो विधियों का उपयोग करता है:

{# Include the hidden fields #}
{% for hidden in form.hidden_fields %}
{{ hidden }}
{% endfor %}
{# Include the visible fields #}
{% for field in form.visible_fields %}
    <div class="fieldWrapper">
        {{ field.errors }}
        {{ field.label_tag }} {{ field }}
    </div>
{% endfor %}

यह उदाहरण छिपे हुए फ़ील्ड में किसी भी त्रुटि को संभालता नहीं है। आमतौर पर, एक छिपे हुए क्षेत्र में एक त्रुटि फार्म छेड़छाड़ का संकेत है, क्योंकि सामान्य प्रपत्र इंटरैक्शन उन्हें बदल नहीं सकता है। हालाँकि, आप आसानी से उन फ़ॉर्म त्रुटियों के लिए कुछ त्रुटि डिस्प्ले सम्मिलित कर सकते हैं।

पुन: प्रयोज्य प्रपत्र टेम्पलेट

यदि आपकी साइट कई स्थानों में फ़ॉर्म के लिए एक ही प्रतिपादन तर्क का उपयोग करती है, तो आप स्टैंडअलोन टेम्पलेट में फ़ॉर्म के लूप को सहेजकर और अन्य टेम्प्लेट में पुन: उपयोग करने के लिए include टैग का उपयोग करके दोहराव को कम कर सकते हैं:

# In your form template:
{% include "form_snippet.html" %}

# In form_snippet.html:
{% for field in form %}
    <div class="fieldWrapper">
        {{ field.errors }}
        {{ field.label_tag }} {{ field }}
    </div>
{% endfor %}

यदि टेम्प्लेट में पास की गई फॉर्म ऑब्जेक्ट का संदर्भ के भीतर एक अलग नाम है, तो आप इसे include टैग के तर्क के with उपयोग कर सकते include :

{% include "form_snippet.html" with form=comment_form %}

यदि आप स्वयं को अक्सर ऐसा करते हुए पाते हैं, तो आप एक कस्टम समावेश टैग बनाने पर विचार कर सकते हैं।

आगे के विषय

यह मूल बातें शामिल करता है, लेकिन रूपों एक पूरी बहुत कुछ कर सकते हैं:

यह भी देखें

प्रपत्र संदर्भ
प्रपत्र फ़ील्ड, फ़ॉर्म विजेट और फ़ॉर्म और फ़ील्ड सत्यापन सहित पूर्ण API संदर्भ शामिल करता है।