किसी वेब एप्लिकेशन में, क्या यह आपके कोड (गैर-लिखित भाषाओं, जावा, .NET) में HTML का उपयोग करने के लिए स्वीकार्य है?क्या एचटीएमएल कोड के साथ सह-अस्तित्व में होना चाहिए?
दो प्रमुख उप सवाल कर रहे हैं?
आम तौर पर, प्रस्तुति (HTML) को तर्क ("बैक-एंड" कोड) से अलग रखना बेहतर होता है। आपका कोड इस तरह से बनाए रखने के लिए decoupled और आसान है।
इसकी धुंधली, और सुरक्षित प्रकार नहीं है। लेकिन लोग बिना किसी परिणाम के करते हैं। मैं कम से कम, डीओएम या टाइप सुरक्षित सेफेंटिक्स का उपयोग कर एचटीएमएल लिखने के लिए डिज़ाइन की गई कक्षाओं का उपयोग करना पसंद करूंगा। इसके अलावा, तर्क के साथ UI को मिश्रित करने के लिए यह सब अच्छा नहीं है ...
जब तक आपका HTML-लेखन कोड आपके एप्लिकेशन तर्क से अलग होता है, और HTML को किसी भी तरह से अच्छी तरह से गठित होने की गारंटी दी जाती है, तो आपको ठीक होना चाहिए ।
मार्कअप-आधारित पृष्ठों (यानी, जिनमें शाब्दिक HTML शामिल हैं) में मिश्रित किया जाने वाला एकमात्र कोड HTML है (उदाहरण के लिए, एक सूची लिखने के लिए एक लूप) के लिए उपयोग किया जाने वाला कोड है।
व्यापार-बंद हैं चाहे आप HTML के साथ कोड डालते हैं या आप उद्धृत स्ट्रिंग अक्षर का उपयोग करके HTML को लिखने के लिए शुद्ध कोड का उपयोग करते हैं।
नहीं, यदि आप अच्छे और रखरखाव योग्य सॉफ्टवेयर बनाना चाहते हैं, और ढीले युग्मन को प्राप्त करना चाहते हैं।
यदि मुझे HTML उत्पन्न करने वाली विधियों की आवश्यकता है तो मैं आमतौर पर उन्हें HtmlHelpers क्लास में अलग करता हूं। इस तरह आप कुछ अलगाव के स्तर को रखते हैं। एएसपी.नेट एमवीसी फ्रेमवर्क यह काफी सफलतापूर्वक करता है।
यदि मैं सही प्रश्न समझता हूं, तो आप पूछ रहे हैं कि बैक-एंड कोड के साथ मार्कअप मिश्रण करना एक अच्छा अभ्यास है या नहीं। नहीं। हालांकि यह आमतौर पर किया जाता है, यह अभी भी एक बुरा विचार है।
आप MVC प्रतिमान पर पढ़ना चाहिए, साथ ही इस तरह के What is the best way to migrate an existing messy webapp to elegant MVC? और Best practices for refactoring classic ASP?
के रूप में इस मामले पर मौजूदा सवाल, पर के रूप में आप अपने कोड में एचटीएमएल प्रिंट मतलब, तो कोई है। जब तक आपके पास कोई अच्छा कारण न हो, आपको templates
का उपयोग करना चाहिए, भले ही आपको लगता है कि आपको इसकी आवश्यकता नहीं है, फिर भी आपको हमेशा इसकी आवश्यकता होगी। हो सकता है कि आप HTML से भिन्न प्रारूप में आउटपुट करना चाहते हैं, या आप एक ही डेटा के लिए अलग-अलग प्रस्तुति चाहते हैं। आपको आमतौर पर सड़क के नीचे इन चीजों की आवश्यकता होती है, इसलिए शुरुआत से ही इसका उपयोग करना सबसे अच्छा होता है।
बिंदु डिस्प्ले तर्क को शेष कोड से अलग रखना है। किसी भी जटिल साइट में आपके कोड को आपके एचटीएमएल के साथ मिश्रित किया जाएगा, लेकिन कोड केवल प्रदर्शन उद्देश्यों के लिए होना चाहिए। यह किसी भी जटिल गणना नहीं करनी चाहिए।
उदाहरण के लिए, टेम्पलेट्स में लूप और सशर्त होंगे। इसके अलावा आपके पास शायद एचटीएमएल-विशिष्ट दिनचर्या की लाइब्रेरी होगी, जैसे किसी सूची वस्तु के आधार पर < विकल्प > सूची प्रिंट करना।
कल्पना कीजिए कि आप एक ऐसे एप्लिकेशन को लिख रहे थे जिसमें दो आउटपुट मोड हैं: HTML और कुछ और। डुप्लिकेट कोड से बचने के लिए, आप इसे कैसे लिखेंगे? यह शायद आपको सही दिशा में इंगित करेगा।
जब डेवलपर्स एचटीएमएल का एक गुच्छा प्रिंट करते हैं तो मुझे नफरत है। यह पूरी तरह से अनावश्यक है और किसी भी टेक्स्ट एडिटर में बदसूरत दिखता है जो प्रिंट में प्रिंट/इको स्ट्रिंग दिखाता है।
एचटीएमएल जो दृश्य को बनाता है उसे किसी भी तरह से ब्राउज़र में भेजना पड़ता है। .NET में, प्रत्येक सर्वर नियंत्रण पृष्ठ जीवन चक्र के हिस्से के रूप में अपना स्वयं का HTML मार्कअप उत्सर्जित करता है। तो हाँ सर्वर साइड कोड में एचटीएमएल का उपयोग करना ठीक है।
शायद आपको एएसपीनेट पैटर्न का पालन करने का प्रयास करना चाहिए। उन नियंत्रणों का एक समूह बनाएं जो यूआई तत्वों का प्रतिनिधित्व करते हैं और उन्हें अपने स्वयं के एचटीएमएल को अपने राज्य के आधार पर उत्सर्जित करने के लिए जिम्मेदार बनाते हैं।
मैं हर किसी के साथ सहमत हूं कि आपको एप्लिकेशन तर्क से HTML/XHTML मार्कअप को अलग करने के लिए जितना कठिन प्रयास करना चाहिए। हालांकि, कभी-कभी आपको विभिन्न कारणों से एप्लिकेशन तर्क में HTML/XHTML उत्पन्न करने की आवश्यकता होती है।
इन मामलों में जो मैं करने की कोशिश कर रहा हूं यह सुनिश्चित करने के लिए है कि आवेदन तर्क के साथ कम से कम प्रस्तुति कोड मिश्रित किया गया हो और प्रस्तुति कोड पर अन्य सभी को माइग्रेट करने का प्रयास करें। यह कुछ भी मूल्यवान नहीं है कि कुछ मामलों में आपके पास ऐसी स्थितियां हैं जहां आप सब कुछ प्रेजेंटेशन लेयर पर ले जा सकते हैं, लेकिन एप्लिकेशन तर्क के हिस्से के रूप में मार्कअप उत्पन्न करना थोड़ा आसान हो सकता है। उन मामलों में, आपकी सबसे अच्छी शर्त उस मार्ग पर जाने की संभावना है जो समय के संदर्भ में सबसे अधिक समझ में आता है।
मुझे नहीं लगता कि आपके व्यापार तर्क के अंदर HTML उत्पन्न करने का कोई बहाना है। इसे तब भी न करें जब यह केवल "त्वरित समाधान" हो या जब आप "वापस जाएं और इसे बाद में ठीक करें", क्योंकि ऐसा कभी नहीं होता है।
अन्य प्रश्नों से मेरी स्थिति दोहराए जाने के लिए, इसे नियंत्रित करने के लिए HTML के भीतर कुछ नियंत्रण तर्क (सशर्त, लूप) का उपयोग करना ठीक है। HTML में कोई डेटा मालिश या व्यावसायिक तर्क न करें। आपको अनुशासित होना है, लेकिन यह इसके लायक है। यदि आपकी चिंताओं (जैसे तर्क और प्रदर्शन) अलग हैं तो रखरखाव बहुत आसान है।
आदर्श रूप से आप अपनी प्रस्तुति (UI) कोड और अपने डोमेन (व्यवसाय तर्क) कोड के बीच चिंताओं को अलग करने का लक्ष्य रख रहे हैं।
कारण है कि आप इन दो चिंताओं (किसी भी दिशा में) युग्मन से बचना चाहिए सरल है ...
आप केवल कोड का एक टुकड़ा बदलने के लिए एक कारण होगा। चाहे यह आपके एचटीएमएल डिज़ाइन में संरचनात्मक/स्टाइलिंग परिवर्तनों से हो या आपके व्यवसाय के नियमों से बदल रहा हो, आपको केवल एक ही स्थान पर बदलाव करना होगा।
कुछ हद तक, हालांकि कई शुद्धतावादियों, असहमत आपके डोमेन कोड या ठीक इसके विपरीत के माध्यम से एचटीएमएल कोड छिड़ककर आप अगले डेवलपर हैं जो पढ़ने/इसे बनाए रखने साथ आता है के लिए शोर बनाने हैं।