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

• देश
• क्षेत्र
• शहर
• सड़क
• भूमिगत रेल

मैं एक शहर चुनता हूं, और क्षेत्र और देश के रूप में क्यों नहीं सोचता? या व्लादिमीर क्षेत्र को चुना, मुझे शहरों की सूची में "मॉस्को" की आवश्यकता क्यों है? व्लादिमीर क्षेत्र के लिए "मेट्रो" क्षेत्र भी प्रासंगिक नहीं है, और जब स्ट्रुनिनो शहर चुना जाता है, तो आमतौर पर नकली। 5 साल के लिए कॉर्पोरेट वेब अनुप्रयोगों में ग्राहक पक्ष के विकास में लगे होने के नाते, मुझे अभी भी पता था कि फॉर्म को स्मार्ट कैसे बनाया जाए। मुझे आशा है कि मेरा अनुभव आपके लिए उपयोगी होगा।

ईआरपी सिस्टम में फॉर्म की मूल आवश्यकताएं इस प्रकार हैं:

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

एक तरीका या दूसरा, यह दो तरीकों से हल किया जाता है:

1. कई अति विशिष्ट रूपों में महारत हासिल होती है।
2. सार्वभौमिक रूप जो कई घटनाओं में अपना राज्य बदलते हैं (कम से कम मूल्यों को बदलते समय)।

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


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

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

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

डायनामिक्स तत्व

ठीक है, ठीक है, हम वहाँ कुछ छिपाएँगे, कुछ दिखाएँगे, कहीं फ़िल्टर करेंगे ... रुकना बंद करो! इतना सरल नहीं है। सबसे पहले, प्रबंधन करने के लिए तीन मुख्य चीजें हैं:

1. दृश्यता
2. कर्तव्य
3. उपलब्धता

यदि पहुंच और प्रतिबद्धता कम और कम स्पष्ट होती जा रही है, तो दृश्यता तुच्छ से दूर है, और इसका प्रबंधन निकटता से जुड़ा हुआ है जिस तरह से खेतों को रखा गया है (नुकसान हो गए हैं)।

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

निश्चित रूप

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

इस छेद को कैसे बंद करें? माना कि यहां हम पता लगाते हैं, लेकिन अगर संरचना अधिक जटिल है? 3 कॉलम कॉलम और खेतों का एक समूह कहें? हम यह सब मापेंगे और नहीं करेंगे।

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

रबड़ के सांचे

लेकिन रबर के रूपों के बारे में क्या है जो पूर्ण निर्देशांक में तय नहीं हैं? सब ठीक हो जाएगा! छेद बस ढह जाएगा:


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

यह समस्या ऐसे समय में समाप्त हो जाती है जब केवल फॉर्म के क्षेत्र ही कम होते हैं। मैं एक सुंदर, घुंघराले आकार लेना चाहता हूं। खेतों के कुछ स्तंभों के साथ, एक बुकमार्क बार के साथ जहां समूह और अन्य अच्छे के साथ सारणीबद्ध भाग होंगे।

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



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

और गतिकी कहाँ से आती है?

इसे सर्वर (K.O.) से लिया जाता है। वास्तव में, यह कुछ नियमों का एक सेट है जो उपयोगकर्ता द्वारा (दृढ़ता से वांछनीय) इंटरफ़ेस के माध्यम से निर्धारित किया जाता है। गतिकी की सबसे सरल ईंट हैल्प (फील्ड-कंडीशन-वैल्यू)। यह अभिव्यक्ति सरल है: "यदि फ़ील्ड का मान मान के बराबर है, तो फ़ील्ड दिखाई देता है, अन्यथा यह दिखाई नहीं देता है।" हालत मानक के साथ फार्म पर कुछ क्षेत्र से एक निश्चित मूल्य की तुलना करता है, और, चयनित स्थिति के आधार पर, यह एचएसएस जिस क्षेत्र से संबंधित है, वह इसकी स्थिति (दृश्यता, पहुंच, अनिवार्य) को बदलता है। उदाहरण के लिए, इस रूप में "मेट्रो" क्षेत्र को छिपाने के लिए एक सहायता है, अगर यह शहर में नहीं है। यह ऐसी बुनियादी स्थितियों पर है कि गतिकी का निर्माण किया जाता है। बेशक, यह न केवल PUZ-ah पर हो सकता है। यह दस्तावेज़ की स्थिति, ऑपरेशन में उपलब्ध क्षेत्र और बहुत सारे डरावने शब्द हो सकते हैं। लेकिन ग्राहक के स्तर पर, यह सब एक अमूर्तता है और इससे कोई फर्क नहीं पड़ता कि यह कहां से आता है, यह महत्वपूर्ण है कि इसे कैसे काम करना है।

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

सारांश ...

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

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