2009-10-29 23 views
5

में डिज़ाइनर-फ्रेंडली विचार Ip.Net MVC का आनंद ले रहे हैं और मैं इसे आगामी प्रोजेक्ट में उपयोग करने के लिए देख रहा हूं। हालांकि, प्रोजेक्ट का हिस्सा डिजाइनिंग के लिए परियोजना दृश्यों को उनके जैसे चीजों के लिए खुलासा करने में सक्षम होने पर जोर दिया जाता है। एक समस्या जो मैं अनुमान लगा रहा हूं वह यह है कि Asp.Net एमवीसी विचार डेवलपर-केंद्रित हैं। मैं वास्तव में <% बनाम की intracies पर डिजाइनरों को शिक्षित करने के <% = <% foreach की तरह अकेले कुछ जाने के लिए नहीं चाहता ...Asp.Net MVC

उदाहरण के लिए, एक ठेठ MVC मेनू संरचना है।

<div id="menu"> 
<ul> 
     <li><%= Html.ActionLink("Home", "Index", "Main")%></li> 
     <li><%= Html.ActionLink("About", "About", "Main")%></li> 
     <li><% Html.RenderPartial("LogOnUserControl"); %></li> 
    </ul> 
</div> 

मैं बहुत बल्कि UserControls की एक बेड़ा की तरह संदेह से की तरह

<div id="menu"> 
<ul> 
     <li>{ActionLink "Home", "Index", "Main"}</li> 
     <li>{ActionLink "About", "About", "Main"}</li> 
     <li>{Partial "LogOnUserControl"}</li> 
    </ul> 
</div> 

या

<div id="menu"> 
<ul> 
     <li><my:ActionLink text="Home" action="Index" controller="Main" /></li> 
     <li><my:ActionLink text="About" action="About" controller="Main" /></li> 
     <li><my:Partial name="LogOnUserControl" /></li> 
    </ul> 
</div> 

हाँ कुछ के साथ जाने के लिए, कि पिछले दिखता डिजाइनरों बताने के लिए सक्षम होगा। व्यक्तिगत रूप से, मैं वास्तव में ऐसा करने के लिए UserControls का उपयोग करने का प्रशंसक नहीं हूं, अगर केवल उन नियंत्रणों का प्रतिपादन बहुत कुछ और (जैसा कि मैं इसे समझता हूं) के बाद होता है और मैं कुछ ऐसा पसंद करूंगा जो एमवीसी जीवन चक्र के अनुरूप हो । मुझे वास्तव में प्लेसहोल्डर्स का एक सेट और प्रासंगिक प्रतिपादन के साथ बदलने का एक तरीका है।

तो ऐसा करने के लिए सबसे अच्छी जगह कहां है और मैं किस तरह के व्यापार-बंद देख रहा हूं। मैं इस पर आने के लिए कुछ कोणों की कल्पना कर सकता हूं:

  • एक कस्टम व्यूपेज क्लास जहां मैं कुछ प्रासंगिक ओवरराइड कर सकता हूं। ViewPage.RenderView या ViewPage.Framework आरंभ करें, हो सकता है, लेकिन वहां से टेक्स्ट पर आपको कैसे मिलता है, मुझे नहीं पता।
  • कस्टम टेक्स्टवाइटर बनाएं और ViewPage.CreateHtmlTextWriter को ओवरराइड करें जिससे मैं सामान को बदलने के लिए टेक्स्ट आउटपुट को रोक सकता हूं। चक्र में यह बहुत देर हो चुकी है, हालांकि, अगर मैं सावधान नहीं हूं तो अन्य कस्टम फ़िल्टरिंग के साथ गड़बड़ कर दूंगा।
  • अपना खुद का IView और ViewEngine कक्षाएं बनाएं। यह सोचने से पहले कि मैं बहुत बुरी जगह पर जा रहा था, मैं इस मार्ग से बहुत दूर नहीं आया था।
  • कस्टम उपयोगकर्ता नियंत्रण जो आवश्यक कार्यक्षमता की नकल कर सकते हैं।

राय? अन्य विकल्प? क्या मेरा अपना व्यूइंजिन मेरा सबसे अच्छा विकल्प है? मेरा अपना व्यूपेज? या UserControl ऑब्जेक्ट्स पर्याप्त होने जा रहे हैं (कृपया कोई नहीं कहें)?

+1

आपके फ्रंट एंड डिज़ाइनरों को डिफ़ॉल्ट वाक्यविन्यास के साथ ठीक होना चाहिए। मैं इसमें बहुत अधिक प्रयास नहीं करता। किसी भी तरह से, एमवीसी वैसे भी उनकी जरूरतों के लिए एक बड़ा सुधार है। ;) –

+0

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

+0

मैं जितना संभव हो डिजाइनरों के लिए थोड़ा घर्षण चाहता हूं। "उनके द्वारा उपयोग किए जाने वाले कार्यों से बेहतर" पर्याप्त नहीं है। मैं तोड़ने वाले बदलावों से निपटने में ठीक हूं। यदि यह सही हो जाता है (यानी कुछ आसानी से संशोधित में केंद्रीकृत) डिजाइनर पुन: प्रशिक्षण के लिए थोड़ा अपग्रेड दर्द बेहतर होता है। स्पार्क के लिए –

उत्तर

5

Spark पर एक नज़र डालें। यह वाक्यविन्यास आपके उदाहरण के समान है।

+1

+1, लेकिन आपके डिजाइनर अभी भी अनजान नहीं हो सकते हैं। – mxmissile

+0

स्पार्क एचटीएमएल और बैक एंड लॉजिक की एक अजीब उलझन की तरह दिखता है। –

+0

मुझे अनजान डिजाइनर नहीं चाहिए। मैं उन्हें विकासशील सीखने के लिए मजबूर नहीं करना चाहता हूं, जबकि वे इसमें हैं। –

1

चार्ल्स कॉनवे ने कहा, स्पार्क निश्चित रूप से जाने का तरीका है। उदाहरण देखें।

<viewdata text="String" action="String" controller="String"> 
${ Html.ActionLink(controller, action, text) } 

तो फिर तुम कि अन्य दृश्य में की तरह उपयोग: सबसे पहले, आप कोड के साथ _ActionLink.spark में आंशिक दृश्य बनाने

<ActionLink text="Home" action="Index" controller="Main" /> 

तुम सिर्फ अपने डिजाइनरों के लिए आंशिक दृश्य तैयार करना है और फिर वे पसंदीदा शैली में एक निर्माण दृश्य। क्या यह आसान नहीं है?

संपादित करें:

क्षमा करें, कि गलत था।<ActionLink text="Home" action="Index" controller="Main" /> काम नहीं करेगा, क्योंकि घर, सूचकांक और मुख्य चर के रूप में व्यवहार कर रहे हैं। जैसा चाहें उतना करना आसान नहीं हो सकता है।

+0

<एक्शनलिंक टेक्स्ट = "'होम'" एक्शन = "इंडेक्स" कंट्रोलर = "'मेन'" /> करेगा। वे चर नहीं हैं, वे सी # कोड हैं। – queen3

+0

मैं समाधान ढूंढना चाहता था जो डबल कोट्स उपयोग की आवश्यकता नहीं है, क्योंकि यह बहुत सहज नहीं है। – LukLed

0

जबकि जवाब दिए और स्वीकार किए जाते हैं, मैं इस का उदाहरण नहीं दिख रहा है: क्यों तुम सिर्फ प्रयोग नहीं करते:

<li><a href='<%= Url.Action("Home", "Index")%>'>Main</a></li>

स्पार्क में इसी प्रकार के। मैं इसे Html.ActionLink, Html.BeginForm, आदि को पसंद करता हूं, जब भी संभव हो (लगभग हमेशा फॉर्म नियंत्रणों को छोड़कर जहां एचटीएमएल हेल्पर्स के साथ स्वचालित नाम एन्कोडिंग करना आसान होता है)।

और आपके डिजाइनर देखें लिंक देखें।

+0

Url.Action और Html.ActionLink के बीच का अंतर स्वाद का एक है, मुझे लगता है। किसी को भी प्रोग्रामिंग एपीआई सीखने वाले डिजाइनरों की आवश्यकता होगी और न ही एचटीएमएल के अतिरिक्त दर्द को संबोधित किया जाएगा। रेंडरपार्टियल और <% और <% = (और जहां आप जोड़ते हैं या छोड़ते हैं) के बीच का अंतर सीखते हैं। मेरे उद्देश्यों के लिए, यह कार्यात्मक रूप से बराबर है जो मैं टालना चाहता हूं। –

1

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

मैं उन पृष्ठों के विचारों में किसी भी तरह के कोड से पूरी तरह से बचना चाहता था, जिन्हें वे डिजाइन करेंगे, इसलिए मैंने एक टेम्पलेटिंग सिस्टम के साथ जाने का फैसला किया जो आपके बिंदु # 2 के समान कुछ करता है, लेकिन रनटाइम पर नहीं। मैं स्पार्क का भी उपयोग कर रहा हूं, हालांकि यह उपयोगकर्ताओं के लाभ के लिए नहीं है क्योंकि वे कोड की तरह दिखने वाले किसी भी चीज़ को छू नहीं पाएंगे।

मूल रूप से उपयोगकर्ता एक पूर्ण HTML-only टेम्पलेट बनाते हैं जिसमें उपयोगकर्ता नियंत्रण और आंशिक दृश्यों के लिए प्लेसहोल्डर टैग होते हैं। उपयोगकर्ता तब इंटरफ़ेस के माध्यम से टेम्पलेट अपलोड करते हैं जो इसे पार करता है और इसे स्पार्क व्यू में बदल देता है।

उदाहरण के लिए। एक तस्वीर गैलरी के लिए, <gallery /> को !{Html.Gallery(Model)} या <use file="Gallery"/> जैसे कुछ में पार्स किया गया है। विवरण फ़ील्ड के लिए, <desc name="Kitchen" /> को !{Html.Description(Model, x => x.Descriptions.Kitchen)} में पार्स किया गया है। यह भी जांचता है कि "रसोई" वास्तव में उस वस्तु/पृष्ठ के लिए एक संपत्ति है जिसे टेम्पलेट किया जा रहा है, या मॉडल को गैलरी के लिए पास किया जा रहा है, वास्तव में रनटाइम त्रुटियों से बचने के लिए छवियों का संग्रह होता है।

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

+0

कोई बुरा विचार नहीं है। मुझे लगता है कि आप अपने दुभाषिया को रनटाइम पेज लाइफसाइक्ल में डाल सकते हैं, लेकिन चूंकि यह एक तरफा है, एक बार की प्रक्रिया तैनाती के लिए अतिरिक्त कदम रखना संभवतः संभव है। –