केकपीएचपी बेस्ट प्रैक्टिस:

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

इस संबंध में एक मजबूत केकेपीएचपी ऐप (या अन्य एमवीसी ढांचे) के लिए सर्वोत्तम प्रथाओं को क्या माना जाता है?

स्रोत

2010-07-15 seth

मैं मार्ग छोड़ दो सुझाव प्राप्त हो जाने कोड का एक बहुत कुछ के साथ खत्म हो जाएगा का उपयोग नहीं, जो मैं करने के इच्छुक हूं, लेकिन जैसे ही मैंने इसे आजमाने की कोशिश की, मुझे लगता है जैसे मैंने ईंट की दीवार मारा। एक गैर-ढांचे वाले अनुप्रयोग में, मैं सिर्फ एक नई निर्देशिका "व्यवस्थापक" बनाउंगा और वहां अपने सभी व्यवस्थापक विशिष्ट नियंत्रकों को रखूंगा, जिनमें से कई के पास फ्रंट एंड कंट्रोलर के समान नाम होगा और इसलिए उन्हें एक्सेस किया जाएगा: "/ admin/उपयोगकर्ताओं/जोड़ें "। मुझे केक के साथ कुछ ऐसा करने का कोई तरीका नहीं मिल रहा है। क्या मेरा एकमात्र विकल्प/admin_users/add है? – seth

यदि यह आपके परिदृश्य में फिट नहीं है तो व्यवस्थापक मार्ग से परेशान न हों। मैं इसका भी उपयोग नहीं कर रहा हूं, व्यवस्थापक पथ मेरे ऐप में फिट नहीं होते हैं। डुप्लिकेटिंग कोड पूरी तरह से प्रयास का अपशिष्ट है।

आप ठीक दागदार भूमिकाओं के लिए एसीएल नियमों का उपयोग कर सकते हैं, या केवल नियंत्रक के पहले फ़िल्टर() या कार्रवाई की पहली पंक्ति में भूमिका (व्यवस्थापक ध्वज) की जांच कर सकते हैं।

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

स्रोत

2010-07-16 22:27:33 sibidiba

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

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

अपने नियंत्रक फ़ोल्डर में और फ़ोल्डर व्यवस्थापक में फ़ोल्डर "व्यवस्थापक" बनाएं, उपयोगकर्ता_admin_controller.php नियंत्रक फ़ाइल बनाएं। वे फ़ोल्डर संरचना को संकुचित करते हैं, इसलिए आपके पास अभी भी आपके रूट डीआईआर के समान नाम नहीं हो सकते हैं, लेकिन आप उन्हें अभी भी एक फ़ोल्डर में अलग कर सकते हैं।

डिफ़ॉल्ट रूप से हो जाएगा ताकि एक /admin_users/add प्रकार स्थिति है, लेकिन है कि दूसरे भाग के साथ बदलाव किया जा सकता है, कुछ मार्ग:

Router::connect('/admin/users/:action', array('controller'=>'admin_users'))

यह प्रत्येक व्यवस्थापक अनुभाग के लिए किया जा करने के लिए होगा - आदर्श नहीं है, लेकिन मैं केक कोड को संशोधित किए बिना बेहतर तरीके से पता नहीं लगा सकते हैं।

स्रोत

2010-07-16 23:42:53 cincodenada

तो फिर आपका व्यवस्थापक अनुभाग यूआरएल कैसा दिखता है? मुझे लगता है कि यह कोई ब्रेनर नहीं होगा, सिवाय इसके कि उप-निर्देशिकाओं में नियंत्रकों को/subdir/control/action (उदा।/व्यवस्थापक/उपयोगकर्ता/जोड़ें) के माध्यम से एक्सेस करने का कोई अच्छा तरीका नहीं है। क्या आप बस अपने व्यवस्थापक नियंत्रकों को "व्यवस्थापक" के साथ नामित करते हैं (उदा।/Admin_users/add)? – seth

यदि एसीएल/भूमिकाओं का उपयोग करते हैं, तो ऐसे पृष्ठ/क्रियाएं हैं जो या तो व्यवस्थापक के लिए केवल पहुंच योग्य हैं, या व्यवस्थापक के साथ अतिरिक्त कार्यक्षमता है। लेकिन मुझे लगता है कि आप क्या सोच रहे हैं कि मचान का उपयोग करते समय, या व्यवस्थापक अनुभागों के साथ। वहां, आप व्यवस्थापक/उपयोगकर्ता/जैसे चाहें जोड़ने के लिए "व्यवस्थापक रूटिंग" का उपयोग कर सकते हैं। केकेपीएचपी मैनुअल देखें: http://book.cakephp.org/view/46/Routes- कॉन्फ़िगरेशन#Prefix-Routing-544 इसके साथ आपके पास अपने उपयोगकर्ता नियंत्रक में केवल 'admin_add' फ़ंक्शन है, जिसे एक्सेस किया गया है '/ admin/users/add', और उसके बाद एक सामान्य 'add' फ़ंक्शन जिसे'/users/add' के माध्यम से एक्सेस किया जाता है। – cincodenada

मैं एसीएल/भूमिकाओं को पूरी तरह समझता हूं (और लागू किया गया है) और मैं मचान का उपयोग नहीं कर रहा हूं। मेरे पास अभी बहुत सारे फ्रंट एंड एडमिन सेक्शन कंट्रोलर हैं जो वही होंगे। मैं व्यवस्थापक नियंत्रकों को एक उपनिर्देशिका "/ admin" में रखना चाहता हूं और यूआरएल उपसर्ग का उपयोग किए बिना "/ admin" जैसा दिखता है। – seth

मैंने अपने आवेदन के लिए एसीएल का उपयोग किया है और मुझे व्यवस्थापक रूटिंग का उपयोग करने से काफी बेहतर लगता है। यह बहुत आसान है। यदि आप वास्तव में उपसर्ग चाहते हैं, तो आप सामान्य रूटिंग के साथ ऐसा कर सकते हैं।

स्रोत

2010-08-05 16:03:09 Nigel

मैं एसीएल + उपसर्ग का उपयोग कर समाप्त हुआ (जो वास्तव में मेरे मूल कार्यान्वयन से वास्तव में एक बदलाव नहीं है)। मैं अभी भी काफी परेशान हूं कि कैसे केक निर्देशिका संरचनाओं और फ़ाइल नामों और लिंक को संभालता है। यह आदर्श होगा यदि नियंत्रक "व्यवस्थापक" निर्देशिका में था जो कि यूआरएल पथ का हिस्सा बन जाएगा। – seth

मैं सुझाव देता हूं कि फ्रंट-एंड एप्लिकेशन और व्यवस्थापक को दो अलग-अलग अनुप्रयोगों (/app और /admin) में अलग करें। डेटाबेस के साथ सभी "गंदे" काम कर, बस एक साधारण फ्रंट एंड एप्लिकेशन के रूप में व्यवस्थापक के बारे में सोचें।

ऐसा करके, आप यूआरएल में/व्यवस्थापक उपसर्ग का उपयोग करके अपने व्यवस्थापक तक पहुंच सकते हैं या/व्यवस्थापक/वेबूट पर दस्तावेज़ रूट सेट कर सकते हैं और सबडोमेन (यानी admin.myapp.com) का उपयोग कर व्यवस्थापक तक पहुंच सकते हैं।

मॉडल कोड दोहराव से बचने के लिए, आप (अर्थात /vendors/core/models) कुछ साझा किए गए फ़ोल्डर में अपने मॉडल डाल दिया और इस पथ bootstrap.php फ़ाइलें (CakePHP 1.3 के लिए App::build('models' => array(VENDORS . 'core/models/')), CakePHP 1.2 के लिए $modelPaths = array(VENDORS . 'core/models/')) में पथ मॉडल करने के लिए जोड़ सकते हैं।

अपने मॉडल के लिए और अधिक व्यवस्थापक या एप्लिकेशन विशिष्ट सामान जोड़ने के लिए, आप, में/मॉडल अपने मूल मॉडल का विस्तार कर सकता है कोर मॉडल लोड हो रहा है और यह विस्तार करके:

App::import('Model', 'CoreModelName'); 

class CustomCoreModelA extends CoreModelA 
{ 
    function specificMethod() {} 
}

साझा घटकों के लिए बनाया जा सकता है कि, व्यवहार , आदि

स्रोत

2010-09-03 05:53:58 ljank

दो ऐप्स का उपयोग करने के बारे में, मैं सहमत हूं और कुछ ऐसा है जो मेरे पास है। लेकिन विक्रेताओं में आपके डालने वाले मॉडल एक बदसूरत हैक है। इसके बजाय एक ऐप में मॉडल फ़ाइलों को इंगित करने के लिए एक ऐप में एपीपी :: बिल्ड का उपयोग करें। इसमें विशेष रूप से समस्याएं होती हैं जब प्लगइन की बात आती है। इतने सारे dirs में बहुत धीमी लग रही है। – dogmatic69

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

व्यवस्थापक रूटिंग का उपयोग करके बनाया गया ऐप्स और नहीं, और संस्करण हमेशा एक गड़बड़ नहीं है। यदि आपकी कुछ विधियां समान हैं तो आप निम्न कार्य कर सकते हैं।

function add(){ 
$this->_add(); 
} 

function admin_add(){ 
$this->_add(); 
} 

function _add(){ 
... your code ... 
}

मैं एक ही है कि अपनी नहीं सभी अपने कोड शर्त है, और होता व्यवस्थापक मार्ग तुम क्या कर if(... is admin ...) { echo 'blaa'} else { echo 'foo'; }

स्रोत

2010-10-14 11:43:26 dogmatic69

उत्तर

संबंधित मुद्दे