YUD के लिए CRUD विजेट जनरेटर

कार खरीदते समय हैबे और अतिरिक्त विकल्पों पर लेख में क्या टिप्पणी है?



डेटा मॉडलिंग के दृष्टिकोण से, वे दोनों "नेस्टेड" इकाइयाँ हैं जिनका मूल वस्तु से अलगाव में स्वतंत्र महत्व नहीं है।

Yii ( php फ्रेमवर्क ) में Gii है - एक अंतर्निहित कोड जनरेटर है जो आपको माउस के कुछ क्लिक के साथ डेटा मॉडल का उपयोग करके बुनियादी CRUD इंटरफेस बनाने की अनुमति देता है, जो विकास में तेजी लाते हैं, लेकिन केवल स्वतंत्र संस्थाओं पर लागू होते हैं, जैसे ऊपर दिए गए उदाहरणों में लेख या मशीन।

"नेस्टेड" डेटा ऑब्जेक्ट्स के लिए कुछ समान उत्पन्न करने में सक्षम होना बहुत अच्छा होगा, है ना? अब - आप, विवरण के लिए कैट का स्वागत कर सकते हैं।

लेख के अंत में सबसे अधीर के लिए, एक त्वरित शुरुआत के लिए निर्देश दिए गए हैं।

और लेख में रुचि रखने वालों के लिए, एक व्यावसायिक अनुप्रयोग से आंतरिक उपकरण तक के पहलुओं पर विचार किया जाता है:

• व्यवसाय का मामला: विषय द्वारा पोस्टिंग
  
  • मुख्य पर विषयों की सूची
  • संबंधित पदों की सूची
• हुड के तहत: CRUD पर आधारित एक gii जनरेटर
  
  • Gii जनरेटर टेम्पलेट
  • विजेट आधार वर्ग
  • एकीकृत मुखौटा नियंत्रक
• जल्दी शुरू करो
  
  • समर्थन और विकास के बारे में

व्यवसाय का मामला: विषय द्वारा पोस्टिंग

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

एक सरलीकृत व्यावसायिक कार्य पर विचार करें: विभिन्न विषयों द्वारा समूहीकृत संदेशों को प्रकाशित करने के लिए एक वेबसाइट बनाने के लिए।

साइट में निम्नलिखित इंटरफेस होना चाहिए:

1. मुख्य पृष्ठ - भविष्य में विभिन्न विगेट्स का समर्थन करना चाहिए, लेकिन कार्यान्वयन के वर्तमान चरण में केवल एक ही है: कुछ मानदंडों द्वारा फ़िल्टर किए गए विषयों की एक सूची।
2. विषयों की पूरी सूची - तालिका रूप में विषयों की एक पूरी सूची;
3. विषय पृष्ठ - विषय के बारे में जानकारी और इसमें प्रकाशित पदों की सूची।

सुंदर मानक, है ना?

आइए डेटा मॉडल देखें:



इसके अलावा कोई आश्चर्य नहीं। दो वर्गों के मॉडल में हमारा व्यावसायिक तर्क होगा:

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

आवेदन दो नियंत्रकों द्वारा दिया जाएगा:

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

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

दो प्रश्न शेष हैं:

1. मुख्य पृष्ठ पर विषयों की फ़िल्टर की गई सूची कैसे प्रदर्शित करें?
2. विषय द्वारा पदों की सूची कैसे प्रदर्शित करें?

यदि आप एक स्वचालित जनरेटर का उपयोग करके उन्हें हल कर सकते हैं - यह एक ठोस उपलब्धि होगी।

मुख्य पर विषयों की सूची

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

प्रदर्शन के लिए, कई कार्यान्वयन विकल्प हैं।

पहला, गंदा और तेज़, सब कुछ सीधे दृश्य फ़ाइल में करना है ( विचार / साइट / index.php ):

1. ActiveDataProvider बनाएँ;
2. इसे टॉपिक मॉडल के डेटा से भरें;
3. मैन्युअल रूप से आवश्यक फ़ील्ड निर्दिष्ट करते हुए, एक मानक सूची दृश्य / ग्रिड विजेट का उपयोग करके प्रदर्शित करें।

आप थोड़ा आगे जा सकते हैं और इसे सभी को एक अलग दृश्य फ़ाइल में पैक कर सकते हैं, जैसे कुछ दृश्य / साइट / _topic-list-widget.php , इसे मुख्य फ़ाइल से रेंडर कहते हैं। यह थोड़ी अधिक प्रबंधनीयता और व्यापकता देगा, लेकिन यह अभी भी बहुत गंदा दिखता है।

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

लेकिन क्या ऐसा महसूस होता है कि एक्शनइंडेक्स () को संभालने के मामले में इस विजेट का कोड बहुत ही टॉपिककंट्रोलर का कोड दोहराएगा ? और इस कोड को मैन्युअल रूप से लिखना बहुत कष्टप्रद है।

इस कोड को स्वचालित रूप से जनरेट करना बेहतर होगा और फिर समाप्त विजेट को कॉल करें:

<?= \app\widgets\TopicControllerWidget::widget([ 'action' => 'index', 'params' => [ 'query' => app\models\Topic::findBySomeSpecificCriteria() ], ]) ?> 

संबंधित पदों की सूची

विषय / दृश्य पते द्वारा प्रस्तुत विषय को देखने के लिए पेज में विषय के बारे में जानकारी और उसमें प्रकाशित संदेशों की एक सूची होनी चाहिए। हमें मॉडल में विषय के लिए संदेशों की सूची स्वचालित रूप से मिल जाती है यदि हमने तालिकाओं के बीच संबंधों को सही ढंग से कॉन्फ़िगर किया है, ताकि केवल प्रदर्शन प्रश्न बना रहे।

विषयों की फ़िल्टर्ड सूची के साथ सादृश्य द्वारा, हमारे पास लगभग समान विकल्प हैं।

विषय को देखने के लिए दृश्य फ़ाइल के कोड में सब कुछ करने के लिए सबसे पहले है ( विचार / विषय / view.php ):

1. ActiveDataProvider बनाएँ;
2. इसे मॉडल से डेटा के साथ भरें $ मॉडल-> getPosts () ;
3. मैन्युअल रूप से आवश्यक फ़ील्ड निर्दिष्ट करते हुए, एक मानक सूची दृश्य / ग्रिड विजेट का उपयोग करके प्रदर्शित करें।

दूसरा इस कोड को एक अलग प्रस्तुति फ़ाइल में अलग करना है: विचार / विषय / _posts-list-widget.php , बस इतना ही नहीं एक आंखों के निशान के रूप में - कहीं इसे पुन: उपयोग करना अभी भी विफल हो जाएगा।

तीसरा एक पूर्ण-विकसित विजेट है जो मोटे तौर पर एक्शनआईंडेक्स () भाग में सशर्त पोस्टकंट्रोलर के कोड की नकल करेगा, लेकिन मैन्युअल रूप से लिखा गया है।

या कोड को स्वचालित रूप से उत्पन्न करें और समाप्त विजेट को कॉल करें:

 <?= app\widgets\PostControllerWidget::widget([ 'action' => 'index', 'params' => [ 'query' => $model->getPosts(), ], ]) ?> 

हुड के तहत: CRUD पर आधारित एक gii जनरेटर

व्यवसाय कार्य परिभाषित किया गया है, उत्पन्न विजेट के लिए आवश्यकताओं को रेखांकित किया गया है, हम यह पता लगाएंगे कि हम इसे कैसे उत्पन्न करेंगे। Gii में पहले से ही CRUD नियंत्रक के लिए एक जनरेटर है। एक CRUD विजेट के लिए, हमें मौजूदा एक के आधार पर एक नया जनरेटर बनाने की आवश्यकता है।

शुरू करने से पहले प्रलेखन के लिए कुछ लिंक - यह भी उपयोगी होगा यदि आप अपना विस्तार लिखने का निर्णय लेते हैं:

• वाईआई एक्सटेंशन ;
• Yii जीआईआई टेम्पलेट ;
• Yii gii जनरेटर ।

जाहिर है, सभी कार्यक्षमता Yii एक्सटेंशन में पैक की गई है, जो संगीतकार के माध्यम से स्थापित है और आपके प्रोजेक्ट के विक्रेता फ़ोल्डर में मिलती है।

विस्तार में तीन भाग होते हैं:

1. Gii जनरेटर टेम्पलेट युक्त टेम्प्लेट / क्रूड निर्देशिका ;
2. नियंत्रक। एफपी फ़ाइल - विजेट कॉल के लिए निर्मित मेंड नियंत्रक;
3. Widget.php फ़ाइल सभी जेनरेट किए गए विजेट के लिए बेस क्लास है।

Gii जनरेटर टेम्पलेट

विस्तार कोड उत्पन्न करना चाहिए, इसलिए इसका केंद्रीय भाग Gii जनरेटर है।

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

Gii जनरेटर में निम्नलिखित भाग होते हैं (सभी टेम्प्लेट / क्रूड डायरेक्टरी के अंदर होते हैं):

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

जनरेटर . php और form.php फ़ाइलों में CRUD जनरेटर से मूल लोगों के सापेक्ष ज्यादातर कॉस्मेटिक परिवर्तन होते हैं: फ़ाइल नाम, सत्यापन, विवरण और टूलटिप ग्रंथ, आदि।

टेम्प्लेट फ़ाइलें जनरेट किए गए दृश्य और विजेट कोड के लिए स्वयं जिम्मेदार होती हैं। सबसे पहले, फ़ाइल टेम्प्लेट / क्रूड / डिफॉल्ट / कंट्रोलर। एफपी महत्वपूर्ण है, जो सीधे विजेट क्लास उत्पन्न करने के लिए जिम्मेदार है, जो मूल जनरेटर से कंट्रोलर क्लास से मेल खाता है।

विजेट में CRUD नियंत्रक के समान कार्य होने चाहिए, लेकिन वे थोड़े अलग तरीके से उत्पन्न होते हैं। नीचे दिए गए उदाहरण टिप्पणियों के साथ पीढ़ी का परिणाम दिखाते हैं:

• ActionIndex - सभी मॉडलों के बिना शर्त उत्पादन के बजाय, विधि $ क्वेरी पैरामीटर को स्वीकार करती है;
  
  

   public function actionIndex($query) { $dataProvider = new ActiveDataProvider([ 'query' => $query, ]); return $this->render('index', [ 'dataProvider' => $dataProvider, ]); } 

• ActionCreate और actionUpdate - सफलता के मामले में, पुनर्निर्देशित के बजाय, वे बस सफलता कोड वापस कर देते हैं, आगे की प्रक्रिया निर्मित किए गए मुखौटा नियंत्रक द्वारा प्रदान की जाती है;
  
  

   public function actionCreate() { $model = new Post(); if ($model->load(Yii::$app->request->post()) && $model->save()) { return 'success'; } return $this->render('create', [ 'model' => $model, ]); } 

  
  
• एक्शनडेलीट - डिलीट विजेट प्रदर्शित करने के लिए जीईटी विधि का समर्थन करता है (डिफ़ॉल्ट रूप से - एक बटन) और एक्शन करने के लिए पोस्ट; यदि सफल होता है, तो यह रीडायरेक्ट भी नहीं करता है, लेकिन एक कोड लौटाता है।
  
  

   public function actionDelete($id) { $model = $this->findModel($id); if (Yii::$app->request->method == 'GET') { return $this->render('delete', [ 'model' => $model, ]); } else { $model->delete(); return 'success'; } } 

अंत में, दृश्य फ़ाइलों में निम्नलिखित मूल संपादन होते हैं:

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

विजेट आधार वर्ग

जब जनरेटर अपना काम पूरा कर लेता है, तो यह एप्लिकेशन नेमस्पेस में एक विजेट क्लास बनाएगा। इनहेरिटेंस चेन इस तरह दिखती है: एप्लिकेशन के लिए उत्पन्न विजेट बेस एक्सटेंशन विजेट, क्लास \ ianikanov \ wce \ विजेट से विरासत में मिले हैं, जो बदले में, बेस Yii विजेट, क्लास \ yii's आधार \ विजेट से विरासत में मिला है।

विस्तार विजेट का आधार वर्ग निम्नलिखित कार्यों को हल करता है:

1. दो मुख्य क्षेत्रों को परिभाषित करता है: $ कार्रवाई और $ परम, जिसके माध्यम से कॉलिंग व्यू से विजेट को नियंत्रण स्थानांतरित किया जाता है;
2. कई मानक मापदंडों को परिभाषित करता है जिन्हें उत्पन्न वर्ग में ओवरराइड किया जा सकता है, जैसे कि विजेट की व्यू फाइल्स का मार्ग, मुखौटा नियंत्रक का नाम और पथ (इसके बारे में) और त्रुटि संदेश;
3. दृश्य प्रदान करते समय मानक मापदंडों को परिभाषित करता है: प्रस्तुत करना और प्रस्तुत करना;
4. कंट्रोलर इंफ्रास्ट्रक्चर के समान एक ईवेंट इन्फ्रास्ट्रक्चर प्रदान करता है ताकि स्टैंडर्ड फिल्टर जैसे AccessControl और VerbFilter काम करें ;
5. एक रन विधि को परिभाषित करता है जो यह सब एक साथ इकट्ठा करता है।

एकीकृत मुखौटा नियंत्रक

इन डेटा को प्रदर्शित करने में कोई समस्या नहीं है - विगेट्स इस उद्देश्य के लिए हैं। लेकिन संपादन के लिए, वैसे भी, आपको एक नियंत्रक की आवश्यकता है। प्रत्येक विजेट के लिए एक अद्वितीय नियंत्रक उत्पन्न करें - इसका पूरा सार खो गया है। एक मानक CRUD का उपयोग करना हमेशा प्रासंगिक नहीं होता है, और मैं gii के अतिरिक्त लॉन्च पर निर्भर नहीं होना चाहता। इसलिए, विकल्प का उपयोग एक सार्वभौमिक, एकीकृत नियंत्रक-मुखौटा के साथ किया गया था।

यह नियंत्रक कॉन्फ़िगरेशन फ़ाइल के माध्यम से एप्लिकेशन मैप में पंजीकृत है और इसमें केवल एक ही विधि शामिल है - एक्शनइंडेक्स, जो निम्नलिखित क्रियाएं करता है:

1. एक ग्राहक से अनुरोध स्वीकार करता है;
2. संबंधित विजेट वर्ग के लिए स्थानांतरण नियंत्रण;
3. विजेट के परिणामस्वरूप व्यावसायिक त्रुटियों को संभालता है;
4. मुख्य अनुप्रयोग पर वापस निर्देशित करता है।

शायद यह इंगित करना अधिक महत्वपूर्ण है कि यह नियंत्रक क्या नहीं करता है:

1. यह एक्सेस स्तरों की जांच नहीं करता है - यह तर्क विशिष्ट विजेट्स से संबंधित है;
2. यह कोई इनपुट हेरफेर नहीं करता है - मापदंडों को विजेट में पारित किया जाता है जैसा कि यह है;
3. यह पूर्वनिर्धारित सफलता कोड के लिए जाँच के अलावा आउटपुट में हेरफेर नहीं करता है।

यह दृष्टिकोण आपको सुरक्षा आवश्यकताओं, एप्लिकेशन एप्लिकेशन कोड सहित व्यावसायिक आवश्यकताओं के कार्यान्वयन को छोड़कर, मुखौटा की बहुमुखी प्रतिभा को बनाए रखने की अनुमति देता है।

जल्दी शुरू करो

व्यवसाय चुनौती स्पष्ट है, शुरू करने के लिए तैयार है? एक्सटेंशन का उपयोग करने के चार चरण हैं:

1. स्थापना;
2. विन्यास;
3. पीढ़ी;
4. आवेदन।

एक्सटेंशन का उपयोग कंपोजर का उपयोग करके किया जाता है:

 php composer.phar require --prefer-dist ianikanov/yii2-wce "dev-master" 

अगला, आपको एप्लिकेशन कॉन्फ़िगरेशन फ़ाइल में कई बदलाव करने की आवश्यकता है।

सबसे पहले, gii जनरेटर के लिए एक संदर्भ जोड़ें:

 if (YII_ENV_DEV) { $config['modules']['gii'] = [ 'class' => 'yii\gii\Module', 'allowedIPs' => ['127.0.0.1', '::1', '192.168.0.*', '192.168.178.20'], 'generators' => [ //here 'widgetCrud' => [ 'class' => '\ianikanov\wce\templates\crud\Generator', 'templates' => [ 'WCE' => '@vendor/ianikanov/yii2-wce/templates/crud/default', // template name ], ], ], ]; } 

दूसरे, नक्शे में एकीकृत मुखौटा नियंत्रक जोड़ें:

 $config = [ ... 'controllerMap' => [ 'wce-embed' => '\ianikanov\wce\Controller', ], ... ]; 

यह स्थापना और कॉन्फ़िगरेशन को पूरा करता है।

एक विजेट उत्पन्न करने के लिए:

1. खुला जीआईआई;
2. "CRUD नियंत्रक विजेट" का चयन करें;
3. फार्म फ़ील्ड भरें;
4. कोड देखें और जनरेट करें।

इसके अलावा, विजेट का उपयोग करने के लिए, इसे कार्रवाई और परम को निर्दिष्ट करके बुलाया जाना चाहिए - लगभग उसी तरह जिसे नियंत्रक कहा जाता है।

मॉडल की सूची देखने के लिए विजेट:

 <?= app\widgets\PostControllerWidget::widget([ 'action' => 'index', 'params' => [ 'query' => $otherModel->getPosts(), ], ]) ?> 

एक मॉडल को देखने के लिए विजेट:

 <?= app\widgets\PostControllerWidget::widget(['action' => 'view', 'params' => ['id' => $post_id]]) ?> 

मॉडल निर्माण विजेट (बटन + मोडल में लिपटे हुए):

 <?= app\widgets\PostControllerWidget::widget(['action' => 'create']) ?> 

मॉडल परिवर्तन विजेट (बटन + मोडल में लिपटे हुए):

 <?= app\widgets\PostControllerWidget::widget(['action' => 'update', 'params'=>['id' => $post_id]]) ?> 

मॉडल हटाने विजेट (बटन):

 <?= app\widgets\PostControllerWidget::widget(['action' => 'delete', 'params'=>['id' => $post_id]]) ?> 

विजेट का कोड और सभी दृश्य एप्लिकेशन के हैं और आसानी से बदले जा सकते हैं - कंट्रोलर जेनरेट करते समय सबकुछ वैसा ही है।

समर्थन और विकास के बारे में

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

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