सिम्फनी 2 में फॉर्म आर्किटेक्चर

सिम्फनी 2 में रूपों के साथ काम करने के लिए एक पूरी तरह से नया घटक है , जो कि जहां तक ​​मुझे पता है, आसानी से इन पुस्तकालयों में से अधिकांश को कार्यक्षमता के लिए PHP में बदल देगा और, यदि संभव हो तो, इसे विस्तारित करने में (बेशक, यदि आप जावास्क्रिप्ट के साथ काम करते समय छोटे दोषों को ध्यान में नहीं रखते हैं) । इस घटक के विकास में दो साल से अधिक का समय लगा, हालाँकि मैंने इसके बारे में 2009 के वर्ष या उससे भी पहले कहीं और सोचना शुरू किया। प्रत्येक नए संस्करण के साथ, यह घटक अधिक से अधिक स्थिर होता जा रहा है, और सिम्फनी 2.2 के रिलीज के साथ पूरी तरह से स्थिर संस्करण की उम्मीद है।

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

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


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

इस पोस्ट में आपको इस घटक के "हत्यारा सुविधा" का उपयोग करने के उदाहरण नहीं मिलेंगे, इसके लिए दस्तावेज है। इसके अलावा, आपको इसके उपयोग के बारे में जानकारी नहीं मिलेगी, इसलिए बोलना, संदर्भ से बाहर, चाहे फ्रेमवर्क की परवाह किए बिना। इस तरह की जानकारी का वर्णन किया जाना चाहिए, उदाहरण के लिए, जिस्ट में ।

प्रभाव

फ़ॉर्म घटक को विभिन्न भाषाओं में लिखे गए कई फ्रेमवर्क से प्रभावित किया गया है, जिसमें सिम्फनी 1 , ज़ेंड फ्रेमवर्क 1 , Django , रूबी ऑन रेल्स , स्ट्रट्स और जेएसएफ शामिल हैं । इसके अलावा, आप इसमें फ़ार्मलेट्स , WUI और iData , लाइब्रेरीज़ के साथ काम करने के लिए समानताएँ पा सकते हैं, जो कार्यात्मक प्रोग्रामिंग भाषाओं जैसे लिंक्स, करी और क्लीन के लिए लिखे गए फ़ॉर्म के साथ काम करते हैं।

प्रमुख पहलू

रूपों के साथ काम करने के लिए एक घटक डिजाइन करते समय मुख्य पहलू हैं:

• वृद्धि हुई अमूर्तता
• तानाना
• compositionality
• कार्य अलग करना
• मॉडल बाइंडिंग
• गतिशील व्यवहार

हम इन पहलुओं में से प्रत्येक के बारे में चर्चा करने से पहले देखेंगे कि कार्यान्वित वास्तुकला उन्हें कैसे कवर करती है।

वृद्धि हुई अमूर्तता

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

अपने कोड का वर्णन और पुन: उपयोग करने के लिए उपयुक्त संरचना प्रदान करके अमूर्तता का परिचय इस समस्या को हल करता है।

तानाना

एक्सटेंसिबिलिटी एब्सट्रैक्शन से संबंधित दो अवधारणाओं पर आधारित है:

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

एक्स्टेंसिबिलिटी भी घटनाओं के माध्यम से कार्यक्षमता के अधिक गहराई से विस्तार को संदर्भित करता है। हम इस पर बाद में विचार करेंगे।

संगीतकार

यदि हम अंतिम उदाहरण का विश्लेषण करते हैं, तो हम नोटिस कर सकते हैं कि खेतों ( यौगिक क्षेत्रों , जैसे कि माना उदाहरण, या आदिम वाले , जैसे इनपुट पाठ क्षेत्र) और रूपों में कोई विशेष अंतर नहीं है । और खेतों और रूपों

1. मॉडल से डिफ़ॉल्ट मान स्वीकार करें (सरणियों से, दिनांक से, तार से ...)
2. मूल्यों को परिवर्तित करें ताकि इसे एक दृश्य में उपयोग किया जा सके
3. प्रपत्र HTML
4. उपयोगकर्ता द्वारा दर्ज किए गए मानों को स्वीकार करें
5. मान को वापस मॉडल प्रारूप में बदलें
6. डेटा को मान्य कर सकते हैं

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

1. अपने वंशजों को डिफ़ॉल्ट मान (एरे या ऑब्जेक्ट) पास करें
2. प्रत्येक बच्चे के प्रवेश किए गए मानों को किसी सरणी या ऑब्जेक्ट में वापस करें

कार्य अलग करना

हम ऊपर वर्णित कार्यों को कई विशिष्ट समूहों में विभाजित कर सकते हैं:

• डेटा रूपांतरण
• HTML पीढ़ी (प्रस्तुति)
• मान्यता
• डेटा बाइंडिंग

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

मॉडल बाइंडिंग

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

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

मॉडल बाइंडिंग को एक अंतर बनाने के लिए डिज़ाइन किया गया है। यह दो विचारों पर आधारित है:

1. डुप्लिकेट कोड और / या सेटिंग्स की संख्या को कम करने के लिए फॉर्म के निर्माण के दौरान मौजूदा मेटाडेटा का उपयोग करना ।

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

गतिशील व्यवहार

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

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

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

उच्च स्तरीय वास्तुकला

मुझे प्रपत्रों के साथ काम करने के लिए Symfony2 में परत वास्तुकला का एक उच्च-स्तरीय विवरण प्रस्तुत करना चाहिए। इसकी आधारशिला पर्चा घटक है। यह घटक रूपों के संकलन और प्रसंस्करण के लिए आधार को लागू करता है, और आंतरिक घटनाओं को संभालने के लिए Symfony2 इवेंट मैनेजर का भी उपयोग करता है। इस घटक के ऊपर प्लग-इन एक्सटेंशन की एक परत निहित है:

• कर्नेल स्तर एक्सटेंशन फ्रेमवर्क में लागू फ़ील्ड संरचना (चलो इसे प्रकार कहते हैं ) का विवरण प्रदान करते हैं।
• रूपों के भीतर उपयोगकर्ता इनपुट को मान्य करने के लिए सत्यापन का विस्तार आवश्यक है।
• DI एक्सटेंशन एक निर्भरता कंटेनर के उपयोग की अनुमति देता है।
• CSRF एक्सटेंशन, जैसा कि नाम से पता चलता है, फॉर्म में CSRF सुरक्षा जोड़ता है।
• Doctrine2 एक्सटेंशन ( Doctrine Bridge के साथ प्रदान की गई) Doctrine- विशिष्ट ड्रॉप-डाउन सूचियों और घटकों को जोड़ते हैं जो आपको रूपों में उपयोग के लिए ऑब्जेक्ट मेटाडेटा प्राप्त करने की अनुमति देते हैं।

ऊपरी स्तर में ऐसे घटक होते हैं जो HTML-I के गठन को लागू करते हैं। डिफ़ॉल्ट रूप से, Symfony2 में दो ऐसे घटक हैं: एक टिग के माध्यम से रूपों को प्रदान करने के लिए ( ट्विग पुल के साथ आपूर्ति) और दूसरा अच्छे पुराने PHP के माध्यम से प्रतिपादन के लिए ( फ्रेमवर्क के साथ आपूर्ति)।

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

निम्न स्तर की वास्तुकला

यह खंड प्रपत्र घटक की आंतरिक वास्तुकला पर ध्यान केंद्रित करेगा। जैसा कि पहले ही ऊपर उल्लेख किया गया है, प्रपत्र और उसके सभी भागों को उसी डेटा संरचना में प्रस्तुत किया जाता है जो "लिंकर" डिज़ाइन पैटर्न को लागू करता है। प्रपत्र घटक में, यह संरचना FormInterface इंटरफ़ेस द्वारा वर्णित है। इस इंटरफ़ेस को लागू करने वाला मुख्य वर्ग फॉर्म क्लास है, जिसमें तीन घटकों का उपयोग होता है, जिसके साथ यह पूरी चीज़ काम करती है:

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

इन सभी घटकों को फॉर्म ऑब्जेक्ट के कंस्ट्रक्टर को पास किया जाता है और फॉर्म बनाए जाने के बाद इसे बदला नहीं जा सकता है, क्योंकि इससे फॉर्म की स्थिति में अवांछनीय परिवर्तन हो सकते हैं। चूंकि किसी फॉर्म ऑब्जेक्ट के कंस्ट्रक्टर का इंटरफ़ेस काफी जटिल होता है, एक फॉर्म कंस्ट्रक्टर (FormBuilder) लागू किया गया है, जो इन वस्तुओं के उदाहरणों के निर्माण को सरल बनाता है ।

प्रपत्र का दृश्य डेटा संरचना है जो किसी दृश्य का वर्णन करता है। यही है, सीधे टेम्प्लेट में फॉर्म क्लास को कॉल करने के बजाय, आप फॉर्म व्यू क्लास के एक उदाहरण के साथ काम करेंगे। यह ऑब्जेक्ट केवल प्रस्तुति के लिए विशिष्ट अतिरिक्त जानकारी संग्रहीत करता है, जैसे कि HTML तत्वों के रूपों के नाम , उनकी आईडी आदि।

नीचे दिए गए यूएमएल आरेख वास्तुकला का सार दर्शाता है।



जैसा कि आप इस आरेख से देख सकते हैं, एक रूप के जीवन चक्र में तीन अलग-अलग प्रतिनिधित्व होते हैं:

• जब बनाया जाता है, तो फॉर्म को फॉर्मब्युलर ऑब्जेक्ट्स के पदानुक्रम के रूप में दर्शाया जाता है
• नियंत्रक में, एक फॉर्म को फॉर्म ऑब्जेक्ट्स के पदानुक्रम द्वारा दर्शाया जाता है
• प्रस्तुति के स्तर पर, यह FormView ऑब्जेक्ट्स के पदानुक्रम द्वारा दर्शाया जाता है

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



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

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

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

ऊपर वर्णित अवधारणाओं को निम्नलिखित यूएमएल आरेख में वर्णित किया जा सकता है।

निष्कर्ष

इस पोस्ट में मैं जो दिखाना चाहता था वह यह है कि Symfony2 Form घटक में एक अच्छी तरह से डिज़ाइन किया गया आर्किटेक्चर है जो फॉर्म प्रोसेसिंग के कई महत्वपूर्ण पहलुओं को शामिल करता है।

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

में रुचि रखते हैं? कोड जानें । इसके साथ प्रयोग करें । और हमें इसे आपके पसंदीदा ढांचे में एकीकृत करने में मदद करें।

एक अनुवादक से: इस लेख के अनुवाद मौजूद हैं, लेकिन वे मुझे उच्च गुणवत्ता वाले नहीं लगते थे। हां, और मुझे लगता है कि यह दुख नहीं होगा। , , . .