फ़ाइल प्रबंधक (Silex + Kendo UI) - ट्यूटोरियल

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

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

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




मैंने कोड को ठीक किया, वहां कुछ सुविधाओं का एक गुच्छा जोड़ा और यह लेख लिखा जिसमें मैं यह बताने की कोशिश करूंगा कि मैनुअल के एक गुच्छा के विपरीत, मैं किसी भी तरह से एक ब्लॉग नहीं बना सकता, लेकिन Silex +endo UI पर एक फ़ाइल प्रबंधक कैसे बनाया जाए। एक डेटाबेस के बिना, एक दर्शक और संपादकों के बिना, और अन्य "पतियों" के बिना।

सबसे पहले, मैं यह समझाने की कोशिश कर रहा हूं कि मैंने इन उपकरणों (फ्रेमवर्क) को क्यों चुना।

Silex एक माइक्रोफ़्रामवर्क है जिसके बारे में मैंने कई बार एक समीक्षा सुनी है: "तो यह एक nichrome नहीं है!"। लेकिन यह सच नहीं है, Silex पूरी तरह से तार्किक समाधान है, लेकिन इसमें एक बड़ा Symfony2 लेने और विक्रेताओं के फ़ोल्डर को हटाने में शामिल था। निश्चित रूप से। संगीतकार, "टूल" का आविष्कार किया गया था, जिसके बारे में पहले ही बहुत कुछ लिखा जा चुका है, लेकिन वह जानता है कि कैसे, आवश्यक पुस्तकालयों (विक्रेताओं - विक्रेताओं) के वर्तमान संस्करणों को लेने और डाउनलोड करने के लिए कंपोजर.जसन फ़ाइल की सामग्री के आधार पर। हमें डेटाबेस तक पहुंचने के लिए ओआरएम की आवश्यकता है, हम TWIG टेम्पलेटिंग इंजन से प्यार करते हैं, हम रेडिस में मूल्यों को संग्रहीत करना चाहते हैं। हम कंपोज़र में आवश्यक लिखेंगे। json, php कंपोज़र को निष्पादित करें। थापर कमांड को स्थापित करें, और यहाँ Silex ऐसा नहीं है।
लेकिन फ़ाइल प्रबंधक के लिए, यह कुछ अन्य भारी समाधानों की तुलना में बहुत बेहतर है।

हमें यह तय करने की आवश्यकता है कि हमें silex से क्या आवश्यकता होगी:
1) बेशक, लोकप्रिय ढांचे पर समाधान पहले से ही अपने आप में अच्छा है
2) सत्र के साथ काम करें
3) जवाब के साथ काम करें (प्रतिक्रिया और पुनर्निर्देशन)
4) टहनी टेम्पलेट इंजन
मैं थोड़ा जोड़ूंगा कि मैं टहनी से बहुत प्यार करता हूं और दूसरों को इसका उपयोग करने के लिए प्रोत्साहित करता हूं। मैं टाइपसेटर नहीं हूं, लेकिन बहुत बार मुझे पीएचपी के लिए सामान्य रूप में टेम्प्लेट (दृश्य) में काम करना पड़ता है: अर्थात्। PHP से आवेषण का उपयोग करें। "Php शक्तिशाली है, यह इसका अपना टेम्पलेट इंजन है!" - इसके विपरीत लोग। यह सही है, लेकिन वह बहुत शक्तिशाली है एक टेम्पलेट इंजन। कई बार मैंने खुद को यह सोचकर पाया कि मैं एक टेम्पलेट में तर्क लिखता हूँ! और यह बिलकुल असंभव है! तो टहनी आपको टेम्पलेट बनाने की प्रक्रिया पर पुनर्विचार करती है। यह बहुत कुछ करने में सक्षम होने के लिए शक्तिशाली है, और साथ ही, यह विचारों को टेम्पलेट में "प्रोग्राम" पर छोड़ देता है।

खैर, php ढांचे के साथ उन्होंने फैसला किया - इसे रहने दो। क्यों केडो उई? क्या वह बड़ा है? खैर, वह वास्तव में छोटा नहीं है। लेकिन, सबसे पहले, जिस साइट पर मैंने पहले से ही केडो का उपयोग किया था, और दूसरी बात, इस जेएस ढांचे पर समाधान सुंदर दिखता है।
कीडो से हमें क्या चाहिए:
1) खिड़की
2) फाड़नेवाला
3) अपलोडर
4) मेनूबार
5) ट्रीव्यू
वैसे, अगर हम ऐसे उद्देश्यों के लिए थर्ड-पार्टी जेएस लेते हैं, तो समाधान बहुत छोटा नहीं होगा।

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

प्रतिक्रिया

Symfony2 और निश्चित रूप से Silex में एक बहुत ही सुविधाजनक विशेषता है - वे आपको आउटगोइंग (प्रतिक्रिया) अनुरोधों को प्रबंधित करने की अनुमति देते हैं। यह एप्लिकेशन सक्रिय रूप से जावास्क्रिप्ट का उपयोग करता है, और js (विशेष रूप से jquery ajax) आवेदन से प्रतिक्रिया के लिए अलग तरह से प्रतिक्रिया कर सकता है। दूसरे शब्दों में, यदि अजाक्स फ़ंक्शन 200 के कोड के साथ एक सामान्य प्रतिक्रिया प्राप्त करता है, तो यह इस तरह से प्रतिक्रिया देगा, और यदि त्रुटि अलग है। उदाहरण के लिए, jquery ajax फ़ंक्शन onSuccess (200 ठीक प्रतिक्रिया) और onError (200 नहीं, बल्कि 500, उदाहरण के लिए) तरीके को संभाल सकता है (onSuccess और itError हाल ही में किए गए हैं और विफल हुए)। और HttpFoundation \ Response विक्रेता की मदद से, आप सही कोड के साथ उत्तर भेज सकते हैं।

जहां इसका उपयोग किया जाता है - हम फ़ाइल सिस्टम में फ़ाइल (लोड) को बचाने की कोशिश करते हैं। लेकिन सिस्टम प्रशासक, वहां कुछ स्मार्ट था, और www-data उपयोगकर्ता के बजाय, रूट उपयोगकर्ता के स्वामित्व में फ़ोल्डर बन गया। इसलिए, हम फ़ाइल को सहेज नहीं सकते हैं - पर्याप्त अधिकार नहीं हैं। हम प्राप्त त्रुटि को चर $ इस-> त्रुटि में लिखते हैं। और क्रिया के फंक्शन हैंडलर में (चित्र को सहेजते हुए), आइए इसे करते हैं:

if ($save->handleUpload($sPath, $_thumbPath)) { return new Response('', 200); } else { return new Response($save->getError(), 200); } 

जहां, हैंडल-लोड - फ़ंक्शन जो फ़ाइल को बचाता है, यदि ऑपरेशन सफल होता है - तो TRUE वापस आ जाएगा, अन्यथा FALSE।

नेमस्पेस

Silex php के सभी नवाचारों का उपयोग करने की कोशिश करता है, और विशेष रूप से, सक्रिय रूप से नामस्थान का उपयोग करता है।
सिद्धांत रूप में, आप सामान्य रूप से शामिल का उपयोग कर सकते हैं, लेकिन यह किसी तरह कोषेर नहीं है। हम उस विधि का उपयोग करेंगे जो Silex प्रदान करता है, और वह, हाल ही में, "पता स्थान पंजीकृत करने" के फ़ंक्शन को संगीतकार को स्थानांतरित कर दिया है।

और ऐसा है। हमारे फ़ाइल प्रबंधक में, दो तार्किक भाग हैं:
1) फ़ाइल सिस्टम के साथ काम करते हैं;
2) फ़ाइलों को सहेजना और छवियों के लिए थंबनेल बनाना।
दो कक्षाएं बनाएं: क्लास फाइलें {} और क्लास सेव {}। प्रत्येक वर्ग फ़ोल्डर में एक ही फाइल में स्थित होगा: / src / Fm / Components। ताकि हमारा एप्लिकेशन समझ सके कि इन फाइलों को कहां से डाउनलोड करना है, हम कंपोजर.जॉन में लिखेंगे:

 "autoload":{ "psr-0":{ "Fm" : "src/" } } 

अब कमांड निष्पादित करें:
php कंपोज़र .phar अपडेट

अब आप हमारी कक्षाओं का उपयोग कर सकते हैं, लेकिन इससे पहले, उन्हें घोषित करने के लिए मत भूलना

 use Fm\Component\Save use Fm\Component\Files 

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

निर्भरता इंजेक्शन

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

वापस डीआई के पास। फ़ाइलें () वर्ग कोड में बहुत उपयोग किया जाता है। यदि आप पुराने ढंग से काम करते हैं, तो प्रत्येक क्रिया में, आपको एक नई वस्तु, नई फ़ाइलें () बनानी होगी। DI आपको केवल एक बार एक ऑब्जेक्ट बनाने की अनुमति देता है:

 $app['files'] = function() { return new Files(); }; 

और बाद में पहले से ही इसकी एक प्रति $ ऐप ['फाइलों'] का जिक्र करती है। लेकिन, यह याद रखना महत्वपूर्ण है कि:

 $app['files']->getFiles($dir); //    private $_files; $app['files']->getFolderFiles(); //,   $_files; 

काम नहीं करता है! क्योंकि आपको यह करने की आवश्यकता है:

 $class = $app['files']; $class->getFiles($dir); //    private $_files; $class->getFolderFiles(); //,   $_files; 

दूसरे शब्दों में, हर बार जब आप $ एप्लिकेशन ['फाइल'] का उपयोग करते हैं, तो "सेवा" की एक नई प्रतिलिपि बनाई जाएगी। आप इस तरह एक नई "सेवा" बना सकते हैं:

 $app['some_service'] = $app->share(function () { return new Service(); }); 

फिर आवेदन को निष्पादित करने की प्रक्रिया में हमेशा इसकी एक प्रति होगी।

फ़ाइल प्रबंधक Github पर अपलोड किया गया है।

यह लेख मेंडू यूई लाइब्रेरी को कवर नहीं करता है। सिद्धांत रूप में, अगर कोई इच्छा है - आप फ़ाइल प्रबंधक के विषय को प्रभावित करने वाली सुविधाओं के साथ, इसका त्वरित निरीक्षण कर सकते हैं।

पुनश्च हालांकि कुछ लोगों ने विषय पढ़ा - लेकिन अभी भी:
ckfinder - मुक्त नहीं;
एल्फिंडर सिर्फ प्रबंधक है जो ग्राहक के "बेवकूफ" का कारण बना। इसमें 24 बटन हैं, बिना हस्ताक्षर के, दाहिने क्लिक पर + क्रियाएं;
ये सभी और कई अन्य एफएम एक और php में लिखे गए हैं, यहाँ Silex है, और सभी एप्लिकेशन लॉजिक इन हैं:

/index.php - 11kb
/js/fm.js - 10 kb
+ "मॉडल":
/silex/src/Fm/Compords/Files.php - 11 kb
/silex/src/Fm/Compords/Save.php - 3 kb