🤞 🦄 👩🏽‍💼 वर्ग-आधारित विचार - क्यों और कैसे उपयोग करें 🍛 🧦 🏡

Django संस्करण 1.3 में, वर्ग-आधारित विचारों को पेश किया गया था - कक्षाओं के रूप में दृश्य का वर्णन करने का एक तरीका। हालाँकि, प्रलेखन, केवल सामान्य विचारों की चिंता करता है, वर्गों के रूप में "विचार" लिखने की सामान्य तकनीक का वर्णन नहीं करता है। जेनेरिक विचारों का उपयोग करना शुरू करना और फिर उनके व्यवहार को बदलने की कोशिश करना, मैं धीरे-धीरे उस बिंदु पर पहुंच गया, जहां मुझे कुछ करने के लिए स्रोत कोड को देखना था। इसलिए मैंने इस पाठ को लिखने का फैसला किया। इसका उद्देश्य यह बताना है कि क्लास-आधारित दृश्य का उपयोग कैसे करें और यह कैसे उपयोगी हो सकता है।

प्रेरणा

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

उदाहरण के लिए, हमारे पास प्रकाशक वर्ग है, और हम पृष्ठ पर इस वर्ग की सभी वस्तुओं की एक सूची दिखाना चाहते हैं। Django 1.2 में हम इस तरह से सामान्य दृश्य का उपयोग करते हैं :

# urls.py from django.views.generic import list_detail from books.models import Publisher urlpatterns = patterns('', (r'^publishers/$', list_detail.object_list, { "queryset" : Publisher.objects.all(), }) )

हम बस पैरामीटर शब्दकोश में ब्याज की क्वेरी को पास करते हैं, बाकी सब कुछ हमारे लिए पहले ही लागू हो चुका है।

हालांकि, अगर विकास प्रक्रिया के दौरान "दृश्य" के व्यवहार को बदलने की आवश्यकता होती है, तो मूल रूप से जेनेरिक के रूप में लागू किया जाता है (जो अक्सर होता है), समस्याएं उत्पन्न होती हैं:

सामान्य दृश्य ब्याज के व्यवहार को बदलने वाले पैरामीटर प्रदान नहीं करता है।
जेनेरिक दृश्य के लिए पैरामीटर बनाने वाला कोड वॉल्यूम में अलग से लिखे गए "व्यू" के कोड के बराबर है और URLCONF में निहित है, जहां यह स्पष्ट रूप से इसका नहीं है।

मैं एक ऐसी तकनीक रखना चाहूंगा, जो किसी भी हिस्से में अपने व्यवहार को बदलने में सक्षम होने के साथ-साथ आपको दृश्य लिखने के लिए तैयार Django कार्यक्षमता का उपयोग करने की अनुमति दे।

कक्षाओं पर सामान्य विचार

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

 # views.py from django.views.generic import DetailView from books.models import Publisher class PublisherDetailView(DetailView): model = Publisher

Urls.py में, "दृश्य" नाम के बजाय, वर्णित वर्ग का as_view () विधि अब पारित कर दी गई है:

 urlpatterns = patterns('', (r'^publishers/$', PublisherDetailView.as_view()), )

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

अब, यदि हमें उदाहरण के लिए, टेम्पलेट में दिए गए संदर्भ को बदलना है, तो हम इस श्रेणी में फ़ंक्शन get_context_data () को फिर से परिभाषित कर सकते हैं, जो संदर्भ के गठन में शामिल है। और कोड लाइव होगा जहां यह होना चाहिए - दृश्यों में। यह केवल यह पता लगाने के लिए रहता है कि कौन से कार्य सामान्य दृश्य हैं, और वे क्या करते हैं।

दोष

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

प्रत्येक वर्ग-आधारित सामान्य दृश्य:

बेस क्लास व्यू से निहित;
एक या अधिक अशुद्धियों से प्रभावित ।

अतः, आपको जिस कार्यात्मक सामान्य दृश्य की आवश्यकता है, उसका विस्तार करने के लिए:

प्रलेखन में देखें कि इसमें क्या अशुद्धियाँ हैं;
इन अशुद्धियों में खोजें जो कार्य करते हैं जिसमें आपके लिए ब्याज का व्यवहार लागू होता है;
इस फ़ंक्शन को ओवरराइड करें।

सभी "विचार" कक्षाओं के रूप में

क्लास-आधारित जेनेरिक विचारों का उपयोग करना आपको सभी "विचारों" को कक्षाओं के रूप में लिखने के लिए प्रेरित करता है, जो सभी में दोहराव और संरचना को कम करने के समान विचारों से है। यदि फ़ंक्शन-आधारित सामान्य विचारों में से कोई भी अक्सर आपको सूट नहीं करता है - ऊपर वर्णित कारणों के लिए, तो कक्षा-आधारित सामान्य विचार आपके लिए हमेशा उपयोगी होंगे।

राय

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

व्यू क्लास अपने कार्यों को कॉल कर सकती है (), पोस्ट (), आदि। अनुरोध के प्रकार के आधार पर, वहाँ अनुरोध पारित करना।

उदाहरण

एक वर्ग के रूप में "दृश्य" के सरल कार्यान्वयन का एक उदाहरण देखा जा सकता है, उदाहरण के लिए, यहां । निम्नलिखित एक जटिल उदाहरण है - दस्तावेज़ीकरण से एक उदाहरण का मेरा पुनर्मूल्यांकन - कक्षाओं के रूप में "विचार" लिखने की सुविधा को पूरी तरह से दिखाता है।

कार्य

परियोजना के लिए आवश्यक है कि क्लाइंट द्वारा अनुरोधित किसी भी डेटा को नियमित रूप से HTML पेज के रूप में या JSON ऑब्जेक्ट के रूप में GST अनुरोध पैरामीटर के आधार पर वापस किया जा सकता है।

निर्णय

"विचारों" का एक सामान्य वर्ग लिखना आवश्यक है, जो उत्तर को दो तरीकों से प्रस्तुत करने में सक्षम है, और परियोजना में बाद के सभी "विचारों" से विरासत में मिला है।

Django में, TemplateResponseMixin कार्यान्वित किया गया है, जिसमें रेंडर_to_response () फ़ंक्शन है जो टेम्पलेट_name में निर्दिष्ट टेम्पलेट को एक पैरामीटर के रूप में दिए गए संदर्भ के साथ प्रस्तुत कर सकता है।

आइए, अपना प्रवेश पत्र लिखें, जो HTML के बजाय JSON लौटाएगा:

 class JsonResponseMixin(object): def render_to_reponse(self, context): return http.HttpResponse(self.convert_context_to_json(context), content_type='application/json') def convert_context_to_json(self, context, extract_from_queryset=None): pass

JSON के संदर्भ को परिवर्तित करने के कार्य को पहले से ही समझने की आवश्यकता है कि यह संदर्भ क्या है, इसलिए इसे लागू नहीं किया गया है।

अब हम एक वर्ग लिखते हैं जो HTML और JSON दोनों को वापस करने में सक्षम होगा:

 class MixedView(View, JsonResponseMixin, TemplateResponseMixin): def get_context(self, request): pass def get(self, request, *args, **kwargs): context = self.get_context(request) if request.GET.get('format', 'html') == 'json' or self.template_name is None: return JsonResponseMixin.render_to_reponse(self, context) else: return TemplateResponseMixin.render_to_response(self, context)

प्राप्त फ़ंक्शन दृश्य में घोषित एक को ओवरराइड करता है। GET पैरामीटर के आधार पर, संदर्भ को दो अशुद्धियों में से एक में प्रस्तुत करने के लिए प्रदान किया जाता है, और JSON या HTML लौटाता है। पहले मामले में, आपको एक फ़ंक्शन की आवश्यकता होगी जो इस संदर्भ के अनुवाद को json में परिभाषित करता है। दूसरे मामले में, आपको उस टेम्पलेट के नाम की आवश्यकता होगी जिसमें यह संदर्भ प्रस्तुत किया गया है। कोई भी "दृश्य" जो इस का एक वंशज है उसके पास दो तरीके लागू होने चाहिए: get_context (अनुरोध), जो संदर्भ बनाता है, और Convert_context_to_json (संदर्भ), जो इसे JSON में अनुवाद करता है, और एक निश्चित टेम्पलेट_नाम।

उदाहरण के लिए, अंतिम दृश्य का कार्यान्वयन इस प्रकार हो सकता है:

 class PublisherView(MixedView): def get_context(self, request): context = dict() context['publishers'] = Publisher.objects.all() return context template_name = 'publisher_list.html' def convert_context_to_json(self, context): json_context = dict() json_context['publisher_names'] = [p.name for p in context['publishers']] return json.dumps(json_context, encoding='utf-8', ensure_ascii=False)

निष्कर्ष

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

आपके ध्यान के लिए धन्यवाद, मुझे किसी भी आलोचना में खुशी होगी।

वर्ग-आधारित विचार - क्यों और कैसे उपयोग करें