Django: एक नेस्टेड, पुन: प्रयोज्य घटक डिज़ाइन को कार्यान्वित करना

Question

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

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

नेस्टेड-घटक डिज़ाइन बनाने के लिए अन्य अनुशंसित दृष्टिकोणों का सुझाव देने के लिए स्वतंत्र महसूस करें।

Answer 1

यह एक दिलचस्प समस्या है। आदर्श रूप से आपको प्रतिपादन से पहले डेटाबेस से सभी घटकों को खींचना चाहिए। लेकिन पदानुक्रम को देखते हुए, टेम्पलेट टैग बनाना समझ में आता है। ये टेम्पलेट टैग उपयुक्त डेटा खींच जाएगा। इस समस्या के उद्देश्य के लिए मान लें कि खोज क्षेत्र के कारण डेटाबेस क्वेरी कैश हो जाती है।

Answer 2

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

मैं शुरू में किए गए मेरे शामिल किए जाने के टैग कार्यों स्पष्ट रूप से टैग टेम्पलेट द्वारा इस्तेमाल किया पैरामीटर, ऐसी है कि ले:

पृष्ठ टेम्पलेट

<div>{% my_tag param1 param2 %}</div> 

टैग पुस्तकालय

@register.inclusion_tag('myapp/tagtemplates/my_tag.html') 
def my_tag(param1, param2): 
    return {'param1': param1, 'param2': param2} 

my_tag.html

<div>Blah: {{ param1 }}</div> 
<div>Blip: {{ param2 }}</div> 

... और स्पष्ट रूप से दृश्य संदर्भ को स्थापित करता है।

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

मैं रखरखाव दृष्टिकोण से इस सेटअप से पूरी तरह खुश नहीं हूं। मुझे यह पसंद नहीं है कि मुझे मैन्युअल रूप से ट्रैक करना होगा कि संदर्भ डेटा की अब आवश्यकता नहीं है।मुझे इस तथ्य को पसंद नहीं है कि संघर्ष से बचने के लिए मेरे सीएसएस वर्गों को ध्यान से नामित करना होगा।

मैं अभी भी नए समाधान के लिए खुला हूं, क्योंकि मुझे यकीन नहीं है कि मैंने जो फैसला किया है वह वास्तव में एक सर्वोत्तम अभ्यास है।