Zend फ्रेमवर्क पर कैसे विकसित नहीं किया जा सकता है

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

अपने खुद के लिखने के बजाय मॉडल के अंतर्निहित तरीकों का उपयोग करना

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

$model = new Model();
$some_data = $model -> fetchAll ( array ( 'field1 = ?' => 1 , 'field2 = ?' => 0 ));
$all_data = $model -> fetchAll ();


Dzz.org के साथ रंगीन
लॉजिक का ऐसा मिश्रण प्रत्येक कंट्रोलर फाइल में था, जो कोड को पढ़ने और त्रुटियों को ठीक करने में बहुत हस्तक्षेप करता था, कुछ स्पष्ट निर्भरताएं लगातार दिखाई नहीं देती थीं, महत्वपूर्ण डेटा को ओवरराइट किया गया था। तदनुसार, यह किसी भी मामले में नहीं किया जाना चाहिए, भले ही आप एक छोटी परियोजना विकसित कर रहे हों।

अनुरोध ऑब्जेक्ट तक पहुँचने के बजाय सीधे वैश्विक सरणियों तक पहुँचना

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

आवश्यक होने पर संदर्भ-स्विचिंग का अभाव

अजाक्स अनुरोधों के प्रसंस्करण को लागू करने के लिए, आप तथाकथित का उपयोग कर सकते हैं संदर्भ-स्विच जो प्रतिक्रिया प्रारूप को बदलने का एक सुविधाजनक तरीका है। यदि आप json का उपयोग करते हैं, तो नियंत्रक की init विधि में, निम्न की तरह कुछ सेट करें:

$this -> _helper -> AjaxContext () -> addActionContext ( 'ajax-handler' , 'json' ) -> initContext ( 'json' );


Dzz.org के साथ रंगीन
अब अजाक्स-हैंडलर कार्रवाई में देखने के लिए हस्तांतरित सभी डेटा को जेन्स प्रारूप में बदल दिया जाएगा। यह विधि देखने को अक्षम करने और मैन्युअल रूप से डेटा को जसन में परिवर्तित करने के लिए बेहतर है।

Zend_Form और Zend_Validate का उपयोग करके उपेक्षा करना

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

डेटा सत्यापन का अभाव

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

function addObject(object_id, user_id) {
if (user_id > 0 ) {
$.get( '/realestate/favorite/oid/' + object_id + '/uid/' + user_id, function () {
$( "#addfavorite" + object_id).hide();
});
}
}

function removeObject(object_id, user_id) {
if (user_id > 0 ) {
$.get( '/profile/removefavorite/oid/' + object_id + '/uid/' + user_id, function () {
$( "#removefavorite" + object_id).hide();
});
}
}


Dzz.org के साथ रंगीन
जैसा कि सर्वर-साइड पर बाद में पता चला, user_id को वर्तमान उपयोगकर्ता के पहचानकर्ता के साथ समानता के लिए जाँच नहीं किया गया था, जो एक गंभीर भेद्यता है

एसीएल के बजाय नियंत्रक वर्ग पदानुक्रम का उपयोग करना

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

public function preDispatch () {
// *fail*
if ( ! empty ( $_REQUEST [ 'session' ])) {
session_id ( $_REQUEST [ 'session' ]);
} else {
$auth = Zend_Auth :: getInstance ();
if ( ! $auth -> hasIdentity ()) {
$this -> _redirect ( 'backoffice/auth/login' );
}
}
}


Dzz.org के साथ रंगीन
यह दृष्टिकोण बुरा क्यों है? सबसे पहले, पहुंच अधिकारों का पुनर्वितरण बहुत मुश्किल है। दूसरे, कई भूमिकाओं को बनाए रखना कठिन है। आप लंबे समय तक जारी रख सकते हैं
जेडएफ में इन उद्देश्यों के लिए, एक्सेस कंट्रोल लिस्ट या एसीएल बनाने के लिए एक उत्कृष्ट उपकरण है। व्यक्तिगत रूप से, मैं एक छोटे से प्लगइन का उपयोग करता हूं जो प्रेषण प्रक्रिया के दौरान अनुरोधित कार्रवाई / नियंत्रक के लिए किसी दिए गए उपयोगकर्ता के एक्सेस अधिकारों की जांच करता है। यह विधि आपको एक सरल, आसानी से परिवर्तनीय सूची में पहुंच अधिकार बनाने की अनुमति देती है, जैसे:

//
$this -> addRole ( 'guest' );
$this -> addRole ( 'user' , 'guest' );
$this -> addRole ( 'manager' , 'user' );

//
$this -> add ( new Zend_Acl_Resource( 'guest_allow' ));
$this -> add ( new Zend_Acl_Resource( 'index/index' ), 'guest_allow' );
$this -> add ( new Zend_Acl_Resource( 'index/registration' ), 'guest_allow' );
$this -> add ( new Zend_Acl_Resource( 'error/error' ), 'guest_allow' );

$this -> add ( new Zend_Acl_Resource( 'user_allow' ));
$this -> add ( new Zend_Acl_Resource( 'index/logout' ), 'user_allow' );
$this -> add ( new Zend_Acl_Resource( 'project/index' ), 'user_allow' );
$this -> add ( new Zend_Acl_Resource( 'task/index' ), 'user_allow' );
$this -> add ( new Zend_Acl_Resource( 'task/complete' ), 'user_allow' );
$this -> add ( new Zend_Acl_Resource( 'task/assigned' ), 'user_allow' );

$this -> add ( new Zend_Acl_Resource( 'manager_allow' ));
$this -> add ( new Zend_Acl_Resource( 'project/add' ), 'manager_allow' );
$this -> add ( new Zend_Acl_Resource( 'task/add' ), 'manager_allow' );
$this -> add ( new Zend_Acl_Resource( 'index/add-user' ), 'manager_allow' );

// , -
$this -> deny ( null , null , null );
$this -> allow ( 'guest' , 'guest_allow' , 'show' );
$this -> allow ( 'user' , 'user_allow' , 'show' );
$this -> allow ( 'manager' , 'manager_allow' , 'show' );


Dzz.org के साथ रंगीन

पासवर्ड दर्ज करने के लिए जिम्मेदार प्रपत्र फ़ील्ड में डेटा फ़िल्टर करना

पासवर्ड क्षेत्र से आने वाले डेटा को कभी भी फ़िल्टर न करें! यह उपयोगकर्ताओं को लॉग इन नहीं कर पाने के कारण को खोजने के लंबे प्रयासों से भरा हुआ है। मेरे मामले में, कारण निम्नलिखित था:

$f = new Zend_Filter_StripTags();
$pwd = $f -> filter ( $this -> _request -> getPost ( 'pwd' ));


Dzz.org के साथ रंगीन
यह देखते हुए कि पासवर्ड को एक एन्क्रिप्टेड रूप में संग्रहीत किया जाना चाहिए और कभी भी प्रदर्शित नहीं किया जाना चाहिए, उनमें टैग या रिक्त स्थान की उपस्थिति किसी भी तरह से कमजोरियों को जन्म दे सकती है, और फ़िल्टरिंग कुछ भी नहीं करेगी।

अग्रिम में स्थानीयकरण के लिए प्रदान करना आवश्यक है

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

ViewHelpers से बाहर निकलें

आपको हमेशा url और baseUrl व्यू हेल्पर्स का उपयोग करना चाहिए ताकि url और पथ को स्थैतिक संसाधनों से बनाया जा सके। यह महत्वपूर्ण है क्योंकि आप यह सुनिश्चित नहीं कर सकते कि एप्लिकेशन अन्य डेवलपर्स द्वारा कैसे स्थित होगा। हमारे मामले में, पथ का गठन किया गया था जैसे कि आवेदन मेजबान के मूल में था, जिसने मेरी मशीन को तैनात करते समय कई समस्याएं पैदा कीं।

बूलियन चर के बजाय पाठ स्थिरांक का उपयोग करना

निष्कर्ष में, मैं तार्किक चर को स्ट्रिंग के साथ बदलने के लिए एक दिलचस्प तरीके के बारे में बात करना चाहता हूं। कोड में, मुझे कुछ इस तरह मिला:

if ( $a > $b )
$this -> view -> result = 'ok'
else
$this -> view -> result = 'fail' ;


Dzz.org के साथ रंगीन
यहाँ और कोई स्पष्टीकरण की आवश्यकता नहीं है, मुझे लगता है कि अंतिम पंक्ति बहुत ही स्पष्ट रूप से मेरे लिए है।

निष्कर्ष

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