2010-03-05 8 views
6

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

कुछ डिस्प्ले ऑब्जेक्ट्स में अन्य प्रदर्शन ऑब्जेक्ट्स शामिल हैं जैसे कि प्रस्तुत करना। उपयोगकर्ता सूची ऑब्जेक्ट उपयोगकर्ता ऑब्जेक्ट को एक निश्चित दृश्य में प्रस्तुत करता है (यह विशेष दृश्य उन्हें सूची आइटम में वापस थूकता है ताकि वे सूची में फिट हो जाएं)

मैं इन्हें ZF में चीजों को करने के उचित तरीके से स्थानांतरित करने की कोशिश कर रहा हूं, लेकिन मैं यह तय नहीं कर सकता कि इन सभी को मददगार देखना चाहिए, या यदि वे सभी स्क्रिप्ट/आंशिक हैं।

बस उन्हें स्क्रिप्ट देखने और उन्हें प्रस्तुत करने के साथ -> रेंडर() थोड़ा गंदे लगता है क्योंकि किसी भी जानकारी या पैरामीटर जिन्हें मैं उन्हें पास करना चाहता हूं उसे दृश्य वस्तु को असाइन करना होगा।

आंशिक रूप से कुछ और सही लगता है, यह सुनिश्चित करने के अलावा कि इन में प्रदर्शन तर्क करने के लिए उचित है (यदि 'showNotificationStatus' पैरामीटर के रूप में पारित किया गया है, तो इस अवधि को प्रस्तुत करें)। या यदि आंशिक रूप से अन्य आंशिक रूप से प्रस्तुत करने के लिए इसके कोशेर (उपयोगकर्ता ऑब्जेक्ट को प्रस्तुत करने वाली उपयोगकर्ता सूची)।

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

इनमें से अधिकांश को पता है (ऊपर से जैसे। ShowNotificationStatus) क्या करना है कुछ अतिरिक्त पैरामीटर की आवश्यकता होती है मॉडल को स्वीकार करने जा रहे हैं, कुछ के साथ। इसके लिए उचित उपकरण क्या है?

उत्तर

15

partials के मूल विचार यह है कि वे संभव के रूप में फिर से प्रयोग करने योग्य के रूप में होना रहे हैं - इसलिए क्यों वे अपने स्वयं के चर गुंजाइश है। मैं आंशिक रूप से HTML के छोटे बिट्स के लिए काफी गूंगा कंटेनर के रूप में उपयोग करना पसंद करता हूं। कुछ if() या foreach() कथन के अलावा कोई बड़ा तर्क नहीं है।

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

मुझे लगता है कि दोनों आंशिक और सहायकों का उपयोग करने का सबसे अच्छा तरीका है मददगार ने डेटा सेट अप किया है, फिर इसे आंशिक रूप से पास कर दिया है। इस तरह आपका एचटीएमएल बनाए रखने के लिए बहुत आसान रहता है (और मुझे संदेह है कि हर बार जब कोई echo "<a href='". $my_link . '"/>" टाइप करता है तो बिल्ली का बच्चा कहीं मर जाता है)।

संपादित (विस्तृत करने):

सहायकों के बारे में याद करने के लिए बात यह है कि वे, सामान्य वर्गों की तरह व्यवहार किया जा सकता है तर्क के साथ एक निर्माता का उपयोग और निजी सदस्य हैं।तो जब आप एक सहायक को तुरंत चालू करते हैं, तो आप एक व्यावसायिक ऑब्जेक्ट कर सकते हैं, और उसके बाद कई विधियां हैं जो HTML (आंशिक के माध्यम से) प्रस्तुत करती हैं।

तो मेरे विचार में:

<?php $helper = $this->_helper->MyUserHelper($users); ?> 
<ul> 
    <?php $helper->user_list(); ?> 
</ul> 

यहाँ, user_list() विधि उन्हें में सभी उचित डेटा के साथ <li> तत्वों का एक संग्रह देता है।

मेरे सहायक हो सकता है इस तरह दिखता है:

class MyWidgetHelper 
{ 
    private $_widget; 

    public function __construct($users) 
    { 
    $this->_users = $users; 
    } 

    public function user_list() 
    { 
    // do any necessary logic here 
    // then return the html that gets rendered. 
    // you can call a partial from here, and it just returns an HTML string. 
    return $this->_view->partial('partials/_user_item.phtml', array('users' => $users) 
    } 
} 
+0

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

+0

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

+0

बकाया। धन्यवाद एक गुच्छा ब्रायन! –

0

हेल्पर्स तर्क के लिए हैं (उदा। वस्तु को सरणी में परिवर्तित करें), आंशिक सजावट तर्क के लिए हैं (<ul> पेड़ के रूप में रिकर्सिव सरणी प्रदर्शित करें)।

याद रखो, तुम भी $this->render('anyfile.ext') या include() रूप में अच्छी तरह उपयोग कर सकते हैं।

+0

एक बात है कि मेरे लिए है कि रेखा blurs, है वहाँ सहायकों कि जेडएफ साथ जहाज है कि उपलब्ध कराए गए आंकड़ों से HTML तत्वों बनाने के लिए ठीक कर रहे हैं। Http://zendframework.com/manual/1.10/en/zend.view.helpers.html उदाहरण पर सभी फॉर्म हेल्पर्स देखें। फॉर्म चेकबॉक्स आपके द्वारा पास किए गए डेटा के साथ एक चेकबॉक्स बनाता है –

+1

हेल्पर्स जिनमें भिन्न HTML आउटपुट हो सकता है, 'setPartial() 'का उपयोग करें। आंशिक चलने पर बहुत महंगा होता है (या आप सुनिश्चित हैं कि यह आउटपुट हर बार समान होगा), सहायक में हार्ड कोड एचटीएमएल के लिए आसान है। यदि आंशिक सेट नहीं है, तो डिफ़ॉल्ट मार्कअप पर फ़ॉलबैक के साथ बस 'setPartial() 'को लागू करें। – takeshin

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