व्यवस्थापक पैनल त्रुटियां या लारवेल आर्किड विकास अनुभव

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

1. पोजिशनिंग

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

अंत में, यह केवल बदतर था ... इस संयोजन ने ही अनुभवी उपयोगकर्ताओं को स्थापित करने के लिए धक्का दिया, और नए लोगों ने कुछ स्वतंत्रता के बजाय अपनी सामान्य क्षमताओं को देखने की उम्मीद की।

2. रूप

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

 <form action="..."> <input type="text" name="title"> <input type="text" name="price"> <input type="submit" value=""> </form> 

प्रबंधक, संपादक और उपयोगकर्ता पूरी तरह से संपादन वस्तु के बारे में अधिक से अधिक देखना चाहते हैं और अगर कोई जानकारी एक तालिका से ली जा सकती है, तो कोई समस्या नहीं है, लेकिन जब सूचना बहुत खींची जाती है?

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

 <form action="..." id="main"> <input type="text" name="title"> <input type="text" name="price"> <input type="submit" value=""> </form> <form action="..." id="editors"> <!--    --> <input type="submit" value=""> </form> <form action="..." id="history"> <!--   --> <input type="submit" value=""> </form> 

यह वही है जो मामूली रूप से बदला गया था ... बेशक मामूली बदलाव और सुविधाओं के साथ, लेकिन अर्थ वही रहा। अन्य रूपों के रूप में सभी प्रसंस्करण को अलग समूह बनाने में:

पिछले उदाहरणों पर सुपरइम्पोज़िंग, कोड में प्रत्येक फॉर्म लगभग इस प्रकार दिखता है:

 class Example extends Form { public $name = 'General'; public function rules(): array { return [ 'title' => 'required|max:160' ]; } public function display(): View { return view('main'); } public function persist(Model $model) { //.. return $model->save(); } } 

और पूरे समूह के नियंत्रक में गठन:

 class ExampleController extends Controller { public function index(Model $model) { $form = new FormGroup([ Example::class // editors.. // history.. ]); return $form->render($model); } } 

अपने आप को और कोड के छोटे संगठन को अलग करने के अलावा, यह कोई अन्य परिणाम नहीं लाया। संक्षेप में:

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

3. CRUD

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

एक अलग वर्ग में, बनाने और संपादित करने के लिए आवश्यक फ़ील्ड के साथ-साथ बुनियादी कार्यों का वर्णन किया गया था:

 class Example extends Behavior { public $name = 'Main'; public function rules(): array { return [ 'title' => 'required|max:160' ]; } public function fields(): array { return [ Input::make('title') ->type('text') ->max(160) ->required(), ]; } } 

इस दृष्टिकोण के लिए धन्यवाद, सरल कोड लिखना प्रस्तुति के साथ काम की पूरी कमी के कारण तेज था, लेकिन इसमें काफी समस्याएं थीं:

• कस्टम ऑपरेशन सुविधा के भीतर उपलब्ध नहीं हैं।
• एक गतिशील दृश्य, जैसे लोडिंग जानकारी के साथ मोडल विंडो उपलब्ध नहीं है।
• मामूली विचलन पर, उदाहरण के लिए, चार्टिंग, हम फिर से शैलियों और लिपियों के साथ blade टेम्पलेट लिखने पर लौटते हैं।
• डेटाबेस के अलावा अन्य स्रोतों से डेटा का उपयोग करने में असमर्थता।
• केवल एक तालिका के ढांचे के भीतर काम करें, यह तय किया जा सकता है, लेकिन पहले और अंतिम कार्यान्वयन में यह था।

सुधार

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

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

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

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

स्क्रीन पर प्रदर्शित डेटा को नियंत्रित करने के लिए, आदेश दिए गए हैं जो प्रसंस्करण का ध्यान रखते हैं।

 class ExampleScreen extends Screen { public $name = 'Example Screen'; public function query(Model $model): array { return [ 'model' => $model ]; } public function commandBar(): array { return [ Link::make('-') ->link('http://orchid.software/ru') ->icon('icon-globe-alt'), ]; } public function layout(): array { return [ Layout::rows([ Input::make('model.title') ->type('text') ->max(160) ->required(), ]) ]; } } 

इस विकल्प पर स्टॉप हुआ, क्योंकि यह पूर्ण लेखन और स्वचालित पीढ़ी के बीच एक स्वस्थ संतुलन बनाए रखता है, जबकि समझने योग्य शेष है।