👐🏼 👩🏻‍🍳 🆔 जब अंतर्निहित एमवीसी पर्याप्त नहीं है 👩‍👧‍👧 😋 👩🏾‍🌾

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

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

यहाँ कई बिंदु हैं:

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

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

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

# -*- coding: utf-8 -*- from statistics import OracleSelect, Chart, Table select_traf = OracleSelect('user/password@DB', """select DAY, NSS_TRAF, BSS_TRAF from DAY_TRAFFIC where DAY >= trunc(sysdate,'dd')-32""") chart_traf = Chart(selector=select_traf, x_column='DAY', y_columns=[('NSS_TRAF', u'NSS '), ('BSS_TRAF', u'BSS ')]) table_traf = Table(selector=select_traf, columns=['DAY', 'NSS_TRAF', 'BSS_TRAF']) template = """ {{ chart_traf }} {{ table_traf }} """

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

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

कॉन्फ़िगरेशन फ़ाइल पढ़ना (निष्पादित करना)

यहां बताया गया है कि कॉन्फ़िगरेशन फ़ाइलों का "दुभाषिया" अपने सरलतम रूप में कैसा दिखता है।

 import os from django.template import RequestContext, Template from django.http import HttpResponse, Http404 from settings import PROJECT_ROOT #   ,    __file__   settings.py def dynamic_page(request, report_path): ctx_dict = {} execfile(os.path.join(PROJECT_ROOT, 'reports', report_path + '.py'), ctx_dict) templ_header = '{% extends "base.html" %}{% block content %}' templ_footer = '{% endblock %}' template = Template(templ_header + ctx_dict['template'] + templ_footer) context = RequestContext(request) context.autoescape = False context.update(ctx_dict) return HttpResponse(template.render(context))

हम निष्पादन योग्य का उपयोग करके सेटअप फ़ाइल को निष्पादित करते हैं। स्क्रिप्ट में बनाए गए सभी चर ctx_dict डिक्शनरी में होंगे। हम टेम्प्लेट चर की सामग्री लेते हैं और एक पूर्ण टेम्पलेट बनाते हैं, जिसमें हम मानक RequestContext और उसी स्क्रिप्ट से ताज़ा बनाए गए संदर्भ को स्थानांतरित करते हैं।
Urls.py में जोड़ें

 (r'^reports/(?P<report_path>.+)$', 'statistics.views.dynamic_page'),

एक रिपोर्ट से और उसके संदर्भ में पासिंग

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

 def dynamic_page(request, report_path): ctx_dict = {'get': request.GET.get} ...

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

 chart_name = Chart(select, x_col, config, ..., html_id='chart_name')

यह बेहतर है कि इंजन के यूजर्स को अपनी इनसाइट्स के साथ तनाव न दें, लेकिन निष्पादन में ctx_dict के बनने के बाद आवश्यक आईडी को स्वचालित रूप से असाइन करना है।

  ... execfile(os.path.join(PROJECT_ROOT, 'reports', report_path + '.py'), ctx_dict) for (name, obj) in ctx_dict.items(): if isinstance(obj, (Chart, Table)): obj.html_id = name ...

Ctx_dict के साथ एक और दिलचस्प बात है। चूँकि इसके सभी मान टेम्पलेट के संदर्भ में आते हैं, इसलिए वे RequestContext से पारित समान नामों को फिर से लिखते हैं। उदाहरण के लिए, यदि कुछ संदर्भ प्रोसेसर पृष्ठ शीर्षक में रखने के लिए 'TITLE' मान की गणना करता है, तो आप अपनी सेटअप फ़ाइल में अपनी गणना कर सकते हैं और इसे मौजूदा के बजाय प्रदर्शित किया जाएगा।

 bs = get('bs') if bs is not None: TITLE = u'   %s' % bs

यह स्पष्ट है कि अनजाने में पुनर्लेखन का खतरा है। लेकिन यह नामकरण सम्मेलन द्वारा तय किया गया है (उदाहरण के लिए, संदर्भ में प्रोसेसर केवल ऊपरी मामले का उपयोग करते हैं, और सेटअप फ़ाइलों में केवल निचले मामले में)।

अन्य यूआरएल और बेस पैटर्न के लिए स्केलिंग

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

 import os from django.template import RequestContext, Template from django.http import HttpResponse, Http404 from settings import PROJECT_ROOT from functools import partial def get_param(request, key=None, default=None, as_list=False): if key: if as_list: return request.GET.getlist(key) else: return request.GET.get(key, default) else: return request.GET.lists() class DynamicPage(object): "       " #  view def __init__(self, subpath, # ,   ,       parent_template = "base.html", load_tags = (), #     block_name = 'content', pre_calc = lambda request, context: None, #     execfile post_calc = lambda request, context: None): #     execfile self.templ_header = ('{% extends "' + parent_template + '" %}' + DynamicPage.loading_tags(load_tags) + DynamicPage.block_top(block_name)) self.templ_footer = DynamicPage.block_foot(block_name) self.subpath = subpath self.pre_calc = pre_calc self.post_calc = post_calc @staticmethod def block_top(block_name): if block_name: return "{% block " + block_name + " %}" else: return '' @staticmethod def block_foot(block_name): if block_name: return "{% endblock %}" else: return '' @staticmethod def loading_tags(tags): return ''.join(['{% load ' + tag + ' %}' for tag in tags]) @property def __name__(self): return self.__class__.__name__ #  view def __call__(self, request, pagepath): ctx_dict = self.get_context(request, pagepath) if 'response' in ctx_dict and isinstance(ctx_dict['response'], HttpResponse): return ctx_dict['response'] #    response    #     ,     ,   html- else: template = Template(self.templ_header + ctx_dict['template'] + self.templ_footer) context = RequestContext(request) context.autoescape = False context.update(ctx_dict) return HttpResponse(template.render(context)) def get_context(self, request, pagepath): fullpath = os.path.join(PROJECT_ROOT, self.subpath, pagepath + '.py') if not os.path.exists(fullpath): raise Http404 ctx_dict = {'get': partial(get_param, request), 'request': request} self.pre_calc(request, ctx_dict) execfile(fullpath, ctx_dict) self.post_calc(request, ctx_dict) return ctx_dict

इसने विभिन्न रिपोर्टिंग अनुभागों के लिए गोले बनाने की अनुमति दी। वे प्रोग्रामर द्वारा लगे हुए थे। उत्पादन रिपोर्ट के सिद्धांत नहीं बदले।

उदाहरण के लिए, एक मामले में, html_id वाले उपरोक्त खेलों की आवश्यकता थी।

 def add_html_id(request, context): for (name, obj) in context.items(): if isinstance(obj, (Chart, Table)): obj.html_id = name show_report = DynamicPage('stat_tech/pages', parent_template='stat_tech/base.html', load_tags=['adminmedia', 'jquery', 'chapters'], post_calc=add_html_id)

दूसरे में, कॉन्फ़िगरेशन फ़ाइल से टेम्पलेट का एक ब्लॉक नहीं भरने के लिए, लेकिन दो।

 show_weekly = DynamicPage('stat_weekly/pages', parent_template = 'stat_weekly/base.html', load_tags = ['chapters', ' employees'], block_name=None)

इस स्थिति में, रिपोर्ट फ़ाइल में ही ब्लॉक इंगित किए जाते हैं

 template = """ {% block chart %} {{ costs_monthly }} {{ costs_weekly }} {% endblock %} {% block responsible %} {% employee vasily_pupkin %}, {% employee ivan_ivanov %} {% endblock %} """

तीसरे में, उस इकाई को पहचानने के लिए जिसमें वर्तमान उपयोगकर्ता काम कर रहा है, यह निर्धारित करने के लिए कि कैसे और क्या अनुरोधों को पूरा करना है, और यह भी कि सबमेनू कैसे दिखाना है।

 def add_division(request, context): div = Division.get_by_user(request.user) context['DIVISION'] = div context['SUBMENU'] = calc_goal_submenu(request.path, div) show_goal = DynamicPage('stat_goals/pages', load_tags = ['chapters'], block_name='report', parent_template = 'stat_goals/base.html', pre_calc = add_division)

Urls में, इन सभी आवरणों को नियमित दृश्य के रूप में जोड़ा जाता है

  (r'^stat/(?P<pagepath>.+)$', 'stat_tech.views.show_report'), (r'^weeklyreport/(?P<pagepath>.+)$', 'stat_weekly.views.show_weekly'), (r'^goals/(?P<pagepath>.+)$', 'stat_goals.views.show_goal'),

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

UPD: मैजिक 4x के सुझाव पर, __name__ संपत्ति को डायनेमिकपेज में जोड़ा गया है, जो फ़ंक्शन की नकल को बढ़ाता है।

जब अंतर्निहित एमवीसी पर्याप्त नहीं है

कॉन्फ़िगरेशन फ़ाइल पढ़ना (निष्पादित करना)

एक रिपोर्ट से और उसके संदर्भ में पासिंग

अन्य यूआरएल और बेस पैटर्न के लिए स्केलिंग

More articles: