बूटस्ट्रैप के लिए टेम्प्लेट कैसे न लिखें

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

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

हम ऐतिहासिक रूप से ...

एक नियम के रूप में, यदि किसी साइट को लंबे समय से विकसित किया गया है, तो इसके स्वरूप की आवश्यकताएं नियमित रूप से बदलती हैं। यदि, इसके अतिरिक्त, प्रोग्रामर नियमित रूप से इस पर बदलते हैं, तो कोड (हमारे मामले में, सीएसएस) एक गड़बड़ में बदल जाता है। कहीं बूटस्ट्रैप कक्षाएं, कभी-कभी टेम्पलेट कक्षाएं, यह सब लेआउट डिजाइनरों की कई पीढ़ियों की बैसाखी के साथ पतला है और इनलाइन शैलियों के साथ अनुभवी है। कुछ बदलने की कोशिश या नए जादुई लीड को लंबे जादुई गेम में जोड़ने का प्रयास करें "अनुमान लगाएं कि आपको इस HTML ब्लॉक में कौन सी कक्षाएं लगाने की आवश्यकता है!"। मैं सब कुछ बाहर फेंकना चाहता हूं और इसे खरोंच से फिर से लिखना चाहता हूं। लेकिन यहाँ, वास्तव में, मैं सिर्फ नए फ़ील्ड्स को जल्दी से फ़ॉर्म में जोड़ने के लिए देखा, मेरे पास बैकएंड द्वारा पर्याप्त कार्य हैं ... दरअसल, हम उस कारण पर विचार करेंगे, जिसने मुझे इस लेख को लिखने के लिए प्रेरित किया, पहले उदाहरण में।

इनपुट आकार

इसलिए, हमारे पास फार्म तत्वों का एक मानक दृष्टिकोण है, जिसे हम थोड़ा बदलना चाहते हैं, उदाहरण के लिए, ऊंचाई कम करें। ऐसा करने के तरीके क्या हैं ताकि इनपुट UI व्हेल के अनुरूप हो?

आप इनलाइन स्टाइल सम्मिलित कर सकते हैं! यह बहुत मज़ेदार होगा - फिर इस सभी फुटक्लॉथ को हर इनपुट में कॉपी करें!

कोई हंसेगा, लेकिन मैं नियमित रूप से ऐसे फैसले देखता हूं। सौभाग्य से इस मामले में नहीं है, लेकिन यह करता है। अगर हम ऐसा करते हैं तो क्या होता है? आपको प्रत्येक इनपुट में लंबी शैली के विवरणों को कॉपी करना होगा, टेम्पलेट को फुलाकर इसे कम पठनीय बनाना होगा।

चलो अपनी खुद की कक्षा लिखते हैं, जिसमें हम आवश्यक ऊंचाई सेटिंग्स का वर्णन करेंगे, और उसी समय फ़ॉन्ट आकार बदल देंगे!

हां। वह वह है। «H40_px -16।" वर्ग के नाम से, यह तुरंत स्पष्ट हो जाता है कि वह क्या करता है? मैं कुछ इस तरह से मिला जब मैं यह समझने की कोशिश कर रहा था कि नए इनपुट आवश्यकता से थोड़े मोटे क्यों हैं। मैंने उसी टेम्पलेट में कोड को देखा, और उसे पाया। इस मामले में हमें किन परिणामों की प्रतीक्षा है? सिद्धांत रूप में, कुछ भी महत्वपूर्ण नहीं है। प्रपत्र तत्वों के प्रत्येक वर्ग में, "फॉर्म-कंट्रोल" के अलावा, हम "h40_px-16" जोड़ेंगे। याद करने की जरूरत है, या दस्तावेज़। और अगर हरे रंग की पृष्ठभूमि के साथ फॉर्म के सभी तत्वों को करने की आवश्यकता है? बस एक और वर्ग जोड़ें, "b_g"। और फिर एक और ...

फार्म तत्वों के लिए मौजूदा कक्षाएं बढ़ाएँ?

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

कस्टम समाधान

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

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

1. सबसे पहले, वह बूटस्ट्रैप प्रलेखन को देखता है, और वहां से समाधान की प्रतिलिपि बनाता है।
2. यह देखते हुए कि नेत्रहीन यह UI व्हेल के अनुरूप नहीं है, वह उपयोग किए गए अभिनव समाधान पर प्रलेखन की तलाश करता है।
3. यदि यह प्रलेखन नहीं है (और यह सबसे अधिक संभावना नहीं है), वह कोड में खोज करता है कि यह कैसे लागू किया जाता है।
4. वांछित बेजिक वर्ग की नकल करने के बाद, वह देखता है कि बिल्ला अब सही है, लेकिन नीला है, और उसे लाल रंग की जरूरत है।
5. व्हेल की यूआई के लिए कक्षाओं का वर्णन करने वाली सीएसएस फ़ाइल को खोजने के बाद, यह पता लगाता है कि लाल रंग नहीं रखा गया था, और आहें क्लास "बेजिक-रेड" को जोड़ता है

अब, इस स्थिति की तुलना तब करते हैं जब बैज क्लास को अपने बैज कार्यान्वयन के लिए फिर से परिभाषित किया गया था, और प्रलेखन में रंग कार्यान्वयन का वर्णन किया गया था:

1. सबसे पहले, वह बूटस्ट्रैप प्रलेखन को देखता है, और वहां से समाधान की प्रतिलिपि बनाता है।
2. प्रलेखन पाता है कि लाल को कैसे जोड़ा जाए: बिल्ला-लाल

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

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

यदि आप अपने सहयोगियों को चोट नहीं पहुंचाना चाहते हैं और टीम के काम को गति देना चाहते हैं, तो साइट के लिए अपनी शैली बनाते समय निम्नलिखित नियमों का पालन करें:

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

अंतभाषण

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