ग्रंथों के चित्रों के साथ मचान या कचरे में समय बर्बाद करने के लिए कैसे नहीं

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


सबसे पहले, औसत साइट विकास प्रक्रिया की कल्पना करें:
डिज़ाइन किए गए डिज़ाइनर → लेआउट लेआउट बनाए → सर्वर प्रोग्रामर क्रमादेशित और खींचे गए पैटर्न।

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

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

सर्वर प्रोग्रामिंग और टेम्प्लेट को स्वैप करना तर्कसंगत है:
डिज़ाइन किए गए डिज़ाइनर → सर्वर प्रोग्रामर ने आवश्यकताओं के अनुसार सब कुछ प्रोग्राम किया → डिज़ाइन किए गए डिज़ाइनर।

पहले से बेहतर है। लेकिन अब टेस्ट डेटा बनाने का बोझ सर्वर प्रोग्रामर पर पड़ा और थकाऊपन दूर नहीं हुआ।

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

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

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

_{पुनश्च इस विषय के लिए चित्र Artyom Gorbunov डिज़ाइन ब्यूरो द्वारा रिक्ति स्थल से उधार लिया गया था}