एक उदाहरण के रूप में फोन इनपुट क्षेत्र का उपयोग कर Django प्रपत्र पुस्तकालय में समस्याएं

जैसा कि आप जानते हैं, Django में html रूपों को बनाने और बनाए रखने के लिए एक पुस्तकालय शामिल है। एक बार, Django के साथ एक और फॉर्म लाइब्रेरी आई, लेकिन फिर इसे पूरी तरह से फिर से लिखा गया। शायद, तब डेवलपर्स ने बहुत सी वास्तु समस्याओं को हल किया। लेकिन वर्तमान पुस्तकालय के साथ काम करते समय कुछ कठिनाइयां हैं। यही मैं बात करना चाहता हूं।

तो चुनौती। उपयोगकर्ताओं को अपने फोन और अन्य निजी जानकारी साइटों पर छोड़ने का बहुत शौक है। इसके अलावा, वे इसे सही तरीके से दर्ज करने के बारे में सोचने के बिना ऐसा करना चाहते हैं: 8 (908) 1271669 या, कहें, 908 127 16 69. साइट पर आने वाले लोग सही फोन देखने के बहुत शौकीन हैं, अधिमानतः समान रूप से सजाए गए: (+4995) 722- 16-25, +7 968 ​​127-31-32। यह पता चला है कि आपको संख्याओं को सामान्य रूप में, अर्थात् पंजीकरण के बिना मान्य करने और संग्रहीत करने की आवश्यकता है। जिस क्षेत्र में मैं बात करूंगा, उसमें आप एक से अधिक फोन नंबर दर्ज कर सकते हैं। भंडारण प्रारूप को एक स्थान द्वारा अलग किए गए 11 अंकों के अनुक्रम के रूप में परिभाषित किया गया है।

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

जैसा कि आप देख सकते हैं, प्रपत्र के अंदर डेटा में तीन मार्ग हैं: उपयोगकर्ता के लिए एप्लिकेशन से (प्रारंभिक के माध्यम से जब फार्म पहली बार बनाया गया था), उपयोगकर्ता से उपयोगकर्ता (त्रुटिपूर्ण रूप से दर्ज डेटा का पुन: प्रदर्शन) और उपयोगकर्ता से आवेदन (यदि दर्ज किया गया डेटा सही है)। ठीक है, कार्य सरल लगता है। पहले और तीसरे मार्गों में जागना आवश्यक है, उपयोगकर्ता के लिए फोन को प्रारूपित करना और आवेदन के लिए सामान्य करना। चलो आखिरी के साथ शुरू करते हैं।

पहले, हम भविष्य के क्षेत्र के लिए एक रिक्त स्थान बनाएंगे। जाहिर है, यह चारफिल्ड से विरासत में मिला होगा।

class MultiplePhoneFormField(forms.CharField): #    ,      . phone_code = '' 

प्रलेखन सत्यापन के दौरान मूल्य को संसाधित करने में शामिल सभी तरीकों का वर्णन करता है। आवेदन के लिए सही डेटा प्रकार के लिए to_python () का उपयोग किया जाता है। लेकिन हमारा डेटा प्रकार एक स्ट्रिंग है, इसलिए हम इस पद्धति का उपयोग नहीं करेंगे। अगला, मान्य () और run_validators () विधियाँ। वे प्रवेश किए गए मूल्य की शुद्धता को सत्यापित करने के लिए उपयोग किए जाते हैं, लेकिन वे इसे बदल नहीं सकते हैं, इसलिए वे भी उपयुक्त नहीं हैं। क्षेत्र की स्वच्छ () विधि क्या है। आधार कार्यान्वयन में, यह उपरोक्त विधियों को सही क्रम में कहता है और अंतिम मूल्य देता है। इसलिए, यहां हम कोड डालेंगे।

  def clean(self, phones): phones = super(MultiplePhoneFormField, self).clean(phones) cleaned_phones = [] for phone in phones.split(','): phone = re.sub(r'[\s +.()\-]', '', phone) if not phone: continue if not phone.isdigit(): raise ValidationError(u'   .') if len(phone) == 11: pass elif len(phone) == 10: phone = '7' + phone elif len(self.phone_code + phone) == 11: phone = self.phone_code + phone else: raise ValidationError(u'  .') cleaned_phones.append(phone) return ' '.join(cleaned_phones) 

मैं विस्तार से वर्णन नहीं करूंगा कि संख्या कैसे मान्य है, मुझे लगता है कि सब कुछ स्पष्ट है।

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

बाउंडफिल्ड क्लास में एक as_widget () विधि होती है, जो वास्तविक मान को प्रदर्शित करने के लिए फ़ील्ड का मान उसके मान () विधि को कहकर पास करती है। यह इस पद्धति में है कि यह निर्धारित किया जाता है कि डेटा का स्रोत क्या है - डेटा या प्रारंभिक। और यहां हमें एक बड़ी निराशा का सामना करना पड़ रहा है: यदि डेटा प्रारंभिक से लिया गया है, तो फ़ील्ड को प्रक्रिया में एकीकृत नहीं किया जा सकता है और डेटा को बदल सकता है। मान () विधि बस self.form.initial.get (self.name) को कॉल करती है और फिर, डेटा स्रोत की परवाह किए बिना, उन्हें फ़ील्ड की तैयारी_वेल्यू () पद्धति में भेजती है। यह पता चला है कि सभी मान एक ही पाइपलाइन से गुजरते हैं, जिसके अंत में "सही" मूल्य प्राप्त किया जाना चाहिए।

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

"लेकिन रुकिए, कैसे काम करता है डेटाइमफिल्ड, जो शांति से डेटटाइम को प्रारंभिक रूप से स्वीकार करता है?" आप कहते हैं। तो मैंने सोचा कि कैसे। यह पता चला है कि किसी अज्ञात स्रोत से प्राप्त मूल्य, DateTimeInput विजेट के रेंडर () विधि को पारित किया जाता है, जो बदले में इसे अपने _format_value () विधि से पास करता है। और पहले से ही यह विधि, अगर यह पाता है कि मान डेटाइम है, तो इसे स्ट्रिंग में कनवर्ट करता है। हमारे मामले में भी ऐसा क्यों नहीं किया जा सकता है? क्योंकि आवेदन से पारित मूल्य का प्रकार और फॉर्म जमा होने पर प्राप्त होता है। दोनों मामलों में, यह एक स्ट्रिंग है।

फिर भी, एक समाधान की आवश्यकता है और यह है। यदि आप बाउंडफिल्ड.वेल्यू () विधि को फिर से देखते हैं, तो आप देखेंगे कि उपयोगकर्ता से प्राप्त मूल्य इसके अतिरिक्त बाउंड_डाटा () विधि से पारित किया गया है। इसलिए, तैयार_वायु () विधि में, जहां मूल्य के बाद गिरता है, आप यह निर्धारित कर सकते हैं कि यह पहले कहां से आया है। तो चलिए करते हैं।

 class ValueFromDatadict(unicode): pass class MultiplePhoneFormField(forms.CharField): #    ,      . phone_code = '' def bound_data(self, data, initial): return ValueFromDatadict(data) def prepare_value(self, value): if not value or isinstance(value, ValueFromDatadict): return value return ', '.join(format_phones(value, code=self.phone_code)) 

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

 def format_phones(phones, code=None): for phone in filter(None, phones.split(' ')): if len(phone) != 11: #  . pass elif phone[0:4] == '8800': # 8 800 100-31-32 phone = u'8 800 %s-%s-%s' % (phone[4:7], phone[7:9], phone[9:11]) elif code and phone.startswith(code): # (+7 351) 722-16-25 # (+7 3512) 22-16-25 phone = phone[len(code):] phone = u'(+%s %s) %s-%s-%s' % (code[0], code[1:], phone[:-4], phone[-4:-2], phone[-2:]) else: # +7 968 127-31-32 phone = u'+%s %s %s-%s-%s' % (phone[0], phone[1:4], phone[4:7], phone[7:9], phone[9:11]) yield phone 

यह केवल फॉर्म कंस्ट्रक्टर में शहर कोड को इंगित करने के लिए रहता है, जिसमें संपादित वस्तु जुड़ी हुई है।

 class RestaurantForm(forms.ModelForm): phone = MultiplePhoneFormField(label=u'', required=False, help_text=u'     .') def __init__(self, *args, **kwargs): super(RestaurantForm, self).__init__(*args, **kwargs) if self.instance: self.fields['phone'].phone_code = self.instance.city.phone_code 

खैर, साइट पर फोन प्रदर्शित करने के लिए, यह फिल्टर उपयुक्त है:

 @register.filter def format_phones_with_code(phones, code): return mark_safe(u', '.join([u'<nobr>%s</nobr>' % phone for phone in format_phones(phones, code)])) 

बेशक, हम यह मान सकते हैं कि कार्य हल किया गया था। लेकिन स्पष्ट रूप से बैसाखी के बिना नहीं। यही Django के साथ बंडल किए गए फ़ील्ड कार्यान्वयन के बारे में कहा जा सकता है। उदाहरण के लिए, एक ही DateTimeField फ़ील्ड के to_python () विधि में, एक जाँच है कि मान पहले से ही प्रकार का डेटाटाइम है। इस मामले में, to_python () विधि को केवल डेटा शब्दकोश से प्राप्त मानों के लिए कहा जाता है। डेटा शब्दकोश की सामग्री के बारे में रूपों के लिए प्रलेखन स्पष्ट रूप से कहता है: "ये आमतौर पर तार होंगे, लेकिन कोई आवश्यकता नहीं है कि वे तार हो।" जाहिर है, यह एक पोस्ट अनुरोध से आने वाले उपयोगकर्ता इनपुट के अलावा कुछ और को मान्य करने के लिए कुछ समझ में आता है। लेकिन ऐसा लचीलापन अनिश्चितता का परिचय देता है और सत्यापन को एक एल्गोरिदमिक कार्य के बजाय एक अनुमानी बनाता है।