ASP.NET Webforms डेवलपर्स और वेब डिज़ाइनर: बातचीत कैसे करें?

Question

मैं ASP.NET Webforms डेवलपर हूं, और जब मैं डिजाइनरों के साथ व्यवहार करता हूं तो मुझे कुछ समस्याओं का सामना करना पड़ता है।

डिजाइनर हमेशा शिकायत करते हैं asp.net server controls। बल्कि उनके पास केवल एक html फ़ाइल होनी चाहिए और cssउन लोगों के साथ जाने के लिए आवश्यक छवियों के साथ फाइलें बनाएं । कभी-कभी, यदि डिज़ाइन चरण पहले से किया जाता है, तो मुझे संबंधित सीएसएस फ़ाइलों के साथ HTML फाइलें मिलती हैं, लेकिन फिर हम aspxफ़ाइलों के साथ डिजाइन को एकीकृत करने में कई समस्याओं का सामना करते हैं (गंभीर नियंत्रण एक टेलरिक नियंत्रण ... आदि)।

मैं क्या पूछना चाहता हूँ:

• मैं इन समस्याओं को कैसे दूर करूं? .Net सर्वर नियंत्रण की समस्याओं के कारण डिज़ाइनर php- और mvc डेवलपर्स को पसंद करते हैं। मुझे यह जानने की जरूरत है कि डिजाइनरों के साथ सही तरीके से कैसे बातचीत की जाए।
• क्या .aspx पृष्ठों के प्रदान किए गए (html पृष्ठ) डिजाइनरों को प्रदान करने के लिए कोई उपकरण या एप्लिकेशन हैं? उसके द्वारा मेरा मतलब है Visual Studio में aspx के बजाय रनटाइम में पेज। वे वेब एक्सप्रेशन का उपयोग करते हैं, लेकिन वे html में प्रदान किए गए पेज को भी चाहते हैं।

Comments

नेरफ क्रोटक चमगादड़।

— जोएल एथरटन

रेंडरटाइम html पेज प्रदान करने के लिए कोई टूल? एक वेब सर्वर को इसके लिए काम करना चाहिए।

— psr

यही कारण है कि मैं APT.NET सर्वर नियंत्रणों का उपयोग कभी नहीं करता, अगर मुझे ASP.NET का उपयोग करना होता, तो मैं APT.NET MVC का अलग-अलग उपयोग करता।

— राणीजेक

@ryanzec बिल्कुल रेज़र के विचार इसके लिए बहुत अच्छे हैं, साथ ही छोटे छोटे गतिशील निर्देश और शेष सीधा HTML है। डेवलपर्स को इसके खिलाफ

— डिज़ाइन

@ रायथल - उन्हें स्किन फाइलें दिखाते हुए उन्हें दरवाजे के लिए दौड़ते हुए भेजा जाएगा। अधिकांश फ्रंट-एंड डिजाइनरों के लिए थीम और खाल बिल्कुल बेकार हैं। वे स्टाइलिंग (ज्यादातर) के एक .NET अमूर्त हैं जो वेब डिजाइनरों के लिए स्वाभाविक नहीं हैं।

— ग्राहम

Answer 1

पूर्व डिजाइनर ने, देव को बदल दिया, और मैं वेब नियंत्रणों के बारे में भी नाराज और विलाप करता था। ईमानदारी से, इसका MUCH एक डिज़ाइनर के लिए सस्ता है। एक नेट डेवलपर की तुलना में अपनी प्रथाओं को समायोजित करने के लिए एक GridView के कस्टम इंप्रेशन में तब्दील करने के लिए क्योंकि डिजाइनर ने कहा कि प्रत्येक टीडी में एक 'rel' टैग (या जो कुछ भी) है।

जैसा कि आर्सेनी मूरज़ेंको ने बहुत समझदारी से बताया, वेबफॉर्म का उपयोग करने का निर्णय एक कंपनी की पसंद है जो कोडिंग में कुछ क्षमता प्रदान करते हुए HTML पर नियंत्रण को सीमित करता है। जब तक कंपनी फिर से विचार करने के लिए तैयार नहीं है (जो उन्हें डिजाइनरों को खुश करने के लिए नहीं करना चाहिए), तो डिजाइनरों को इस वास्तविकता को स्वीकार करने की आवश्यकता है। यहाँ कुछ चीजें हैं जो वे कर सकते हैं:

1) किसी भी चीज के लिए आईडी पर निर्भर रहना बंद करें । भले ही यह पहली बार में गलत लगा हो, लेकिन मैंने पाया कि जीवन वास्तव में बहुत आसान था जब मैंने कक्षाओं के साथ सब कुछ स्टाइल किया (और विरासत, निश्चित रूप से)। सबसे पहले, इसने मेरे सभी चयनकर्ता वजन की बराबरी की। CSS विरासत में, ID CLASS CLASS। यह वास्तव में थोड़े अच्छा था कि सब कुछ एक बच्चा और / या कक्षा चयनकर्ता हो, और विशिष्टता क्रम को थोड़ा सरल बना दिया। JS लेयर में भी यही बात है, इसने मुझे क्लास-बेस्ड लोगों के लिए अपने आईडी-बेस्ड सिलेक्टर्स को स्वैप करने के लिए ZERO को दर्द दिया।

2) उन्हें सिखाएं कि RadioButtonLists और CheckboxLists लेबल = अवधि, पैनल = div और अन्य गैर-स्पष्ट नियंत्रण-टू-html सामान के साथ क्या रूपांतरित करते हैं । जिस तरह से .NET इन HTML को रेंडर करता है, वह मेरी अपेक्षा से थोड़ा छोटा था, और मेरे लिए स्क्रीन बनाना बहुत आसान था जब मुझे पता था कि HTML उन नियंत्रणों से कैसे निकलेगी।

3) क्या वे अपने डिजाइनरों को ASPX DIRECTLY में करते हैं , कच्चे HTML ( महत्वपूर्ण ) नहीं। डिज़ाइनर को GridViews, ListViews इत्यादि की मूल बातें सिखाएं, किसी अनाम वस्तु संग्रह को ग्रिड / सूची दृश्य नियंत्रण में धकेलने के लिए उन्हें कुछ कोड स्निपेट दें। यदि वे CSS सीख सकते हैं तो वे इस कोड को कॉपी-पेस्ट करना सीख सकते हैं। वे VS वेब एक्सप्रेस के मुफ्त संस्करण का उपयोग कर सकते हैं, जो अभी CSS & JS काम में काफी अच्छा है। ये डमी वेब परियोजनाएं डिजाइनरों को कुछ नियंत्रण दर्ज करने का मौका देंगी, फिर देखें कि वे कैसे प्रस्तुत किए जाते हैं।

4) बताएं कि .NET में FORM टैग का उपयोग कैसे किया जाता है । पहले इस बारे में भूल गए, लेकिन एक और चीज जो डिजाइनर को इस्तेमाल करनी है वह यह है कि आम तौर पर, एक एकल FORM टैग पूरे पृष्ठ को लपेटता है। यह व्यवहार को नियंत्रित करने के तरीके को बदल देता है, और आप वास्तव में अजीब दुष्प्रभावों के बिना FORM टैग को घोंसला नहीं बना सकते। सुनिश्चित करें कि डिजाइनर इसे समझते हैं या फिर उनका फॉर्म HTML वेबफ़ॉर्म में बनाने के लिए एक बुरा सपना होगा।

5) थीम और स्किन से दूर रहें । भले ही .NET फ्रेमवर्क में इन उपकरणों के लिए एक एप्लिकेशन में शैली नियंत्रण में मदद करने के लिए, वे सामान्य वेब डिज़ाइनरों के लिए अजीब और अजीब हैं, और मैंने उन्हें अपने समय के लायक कभी नहीं पाया। वे देवों के लिए एक अच्छे उपकरण की तरह प्रतीत होते हैं जो सीएसएस में पारंगत नहीं हैं, लेकिन केवल डिजाइनरों को धीमा कर देंगे। डिजाइनरों को उनके प्राकृतिक वातावरण (html और css फ़ाइलें) में काम करने दें और वे अधिक खुश और अधिक उत्पादक होंगे।

6) अपनी साइट के समाधान में "प्रोटोटाइप" प्रोजेक्ट रखें । यह सुनिश्चित करने के लिए कि डेवलपर्स के पास हमेशा कोड के खिलाफ एक लक्ष्य है, डिजाइनरों ने अपने ASPX- केवल पृष्ठों को असली डेवलपर्स द्वारा संरक्षित और अछूता रखने के लिए आपके वास्तविक समाधान में एक नकली वेब परियोजना बनाई है। इसका मतलब यह है कि डिजाइनर अपने प्रोटोटाइप को उसी समाधान में देख सकते हैं, जो असली प्रोजेक्ट के रूप में है कि डेवलपर्स ने कैसे जांच की है, और देवता किसी भी समय प्रोटोटाइप को चला सकते हैं ताकि यह सुनिश्चित हो सके कि उनका काम डिजाइनरों के इरादे से मेल खाता है।

अंत में, MVC में बदलने के लिए किसी भी शिकायत का विरोध करें, जब तक कि आप अपने देवताओं को फिर से प्रशिक्षित करने के लिए तैयार न हों। मैं MVC को व्यक्तिगत रूप से प्यार करता हूं, लेकिन अगर आपको एक टीम WebForms के ज्ञान के साथ मिल गई है, तो बिना किसी कारण के उसे फेंकना मत। यदि आपके एप्लिकेशन में ViewState समस्याएं, एसईओ समस्याएं या पहुंच संबंधी समस्याएं हैं, तो बिल्कुल MVC को एक कठिन स्वरूप दें। लेकिन MVC पर WebForms devs को प्रशिक्षित करने के लिए LOT को अधिक समय लगेगा क्योंकि यह डिजाइनरों को प्रशिक्षित करने के लिए वेब नियंत्रण का उपयोग कैसे करें।

दिन के अंत में, NO DESIGN I CAME ACROSS था, कि मैं व्यक्तिगत रूप से WebForms में काम नहीं कर सकता था, भले ही मैंने एक घंटे के लिए उस झंझरी GridView पर शपथ ग्रहण समाप्त किया हो।

क्या .aspx पृष्ठों के प्रदान किए गए (html पृष्ठ) डिजाइनरों को प्रदान करने के लिए कोई उपकरण या एप्लिकेशन हैं?

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

Comments

आपकी अंतिम पंक्ति ... तो मूल कारण को हल करने के बजाय केवल दीर्घकालिक समाधान को पीड़ित करना और अनुकूल बनाना है? (जहां मूल कारण एक वेब अनुप्रयोग का इलाज है जैसे कि यह एक डेस्कटॉप अनुप्रयोग है)

— अर्लज़ ऑक्ट

@ एर्लज़ - यदि आपके पास विकास कर्मचारियों का एक कर्मचारी है, जिनके पास एक नया प्रतिमान (एमवीसी) लेने के लिए बैंडविड्थ नहीं है, तो यह व्यवसायिक समझ बना सकता है, क्योंकि 1-2 अन्य डिज़ाइनर कर्मचारी वेबफार्म को अनुकूलित नहीं करना चाहते हैं। मैं आपको बता रहा हूँ, यह नहीं है कि एक डिजाइनर के लिए WebForms के लिए अनुकूल है, अगर वे कुछ सामान (आईडी बनाम क्लास शब्दार्थ, लेबल टैग पर सटीक नियंत्रण) जाने के लिए तैयार हैं। देखिए, मैं खुद उस डिज़ाइनर था जो .NET मार्कअप के बारे में लगातार सोचता रहता था, जब तक मुझे एहसास नहीं हुआ कि (जब तक आप एसईओ गेम में नहीं हैं) html source सच तो ये नहीं है। मुझे खेद है, लेकिन यह सच है।

— ग्राहम

@ एर्लज़: मूल कारण यह है कि डिजाइनर वास्तव में माध्यम में काम नहीं कर सकते हैं। मध्यम में काम करने के लिए उन्हें लैस करना संभवत: दीर्घकालिक रूप से सबसे सफल समाधान है।

— वायट बार्नेट

इस तथ्य का भी उल्लेख नहीं है कि एक डिजाइनर कई बार एक डेवलपर की तुलना में प्रति घंटे कम खर्च करता है, इसलिए $ 30ph पर एक डिजाइनर $ 60ph में एक डेवलपर की तुलना में कुछ बदलना बेहतर होगा क्योंकि डिजाइनर इसके बारे में एक बिल्ली है।

— TheMonkeyMan

मेरा पहला इनाम जीता, वाह!

— ग्राहम

Answer 2

आपके मुद्दों का समाधान है लेकिन इसमें एमवीपी में एक डिज़ाइन पैटर्न परिवर्तन शामिल है । यह समय का एक अप-फ्रंट निवेश है जिसे शुरू करने से पहले गंभीरता से विचार करने की आवश्यकता है।

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

यह बहुत व्यापक विषय है जो पैटर्न को जीवन उदाहरण के रूप में देखने के लिए समझ में आता है। आपको यह उदाहरण आपके मामले के लिए बहुत जानकारीपूर्ण लगेगा - एमवीपी पैटर्न के साथ बेहतर वेब फॉर्म ।

संपादित करें: यदि उपरोक्त सुझाव का पालन करना बहुत महंगा (समय और संसाधनों के संदर्भ में) है, तो मैं निश्चित रूप से आपके डिजाइनर के साथ काम करने की सलाह दूंगा । मेरा मानना ​​है कि एक टीम के भीतर अपने मुद्दों को संप्रेषित करने से आपके (डिजाइनर और डेवलपर) काम में आने वाली बाधाओं को हल करने में बहुत मदद मिलेगी। यह एक टीम वर्क है और काम करने के लिए सभी बाधाओं को दूर करने के लिए मुद्दों का अच्छा सहयोग एक टीम के रूप में एक प्रोजेक्ट में सफल होने का तरीका है ! यह कुछ ऐसा है जो हम अपने प्रोजेक्ट में करते हैं।

Comments

+1: यह समस्या का हल (ASP.NET Webforms) दिया गया एक सभ्य समाधान है, लेकिन जैसा कि आप बताते हैं, यह बहुत महंगा हो सकता है क्योंकि इसके लिए बहुत अनुशासन और समय की आवश्यकता होती है (जिसका अर्थ है पैसा)। मेरा तर्क है कि यदि ओपी एक सर्व-समावेशी समाधान में रुचि रखता है, तो उसे ASP.NET MVC (वेबफॉर्म एमवीपी के बजाय) पर स्विच करने पर विचार करना चाहिए। ओपी डिजाइनर के साथ बेहतर संचार के अलावा टीटीएम और डेवलपर प्रतिधारण जैसे कई अन्य लाभों को प्राप्त करेगा।

— जिम जी।

Answer 3

ASP.NET एक फ्रेमवर्क है, जो उत्पन्न HTML कोड को अमूर्त करता है। इसका मतलब है कि आपको ASP.NET एप्लिकेशन में दिए गए HTML कोड को ठीक से पुन: पेश करने के लिए नहीं कहा जा सकता है, जब तक कि आपके पास ASP.NET नियंत्रण द्वारा उत्पन्न किसी भी चीज को फिर से लिखने के लिए पर्याप्त बजट नहीं है ।

यह तय करने के लिए हितधारकों पर निर्भर होगा: या तो आप अपने मजबूत बिंदुओं और नुकसान के साथ ASP.NET नियंत्रणों का उपयोग करते हैं, या आप मैन्युअल HTML (या ASP.NET MVC) पर स्विच करते हैं, जिससे वर्तमान परियोजना की लागत हजारों डॉलर बढ़ जाती है। ।

इस संदर्भ में HTML को अनुकूलित करने में असमर्थता किसी अन्य की तरह एक बाधा है। डिजाइनरों को अपनी नौकरी में इस तकनीकी बाधा पर विचार करना चाहिए।यह मामला बहुत ही समान है यदि डिजाइनर आपको बताएगा कि सटीक आकार के साथ सटीक फ़ॉन्ट में एक पाठ प्रदर्शित किया जाना चाहिए: यह एक वेब समर्थन है, न कि प्रिंट, जिसका अर्थ है कि पाठ का आकार अलग-अलग होगा।

टूल के लिए, मैं उन टूल्स से अनजान हूं जो सादे HTML को ASP.NET टेम्पलेट में बदल देगा। यह संभवतः कैसे अनुमान लगाएगा कि एक विशिष्ट तालिका को एक विशिष्ट ASP.NET नियंत्रण में परिवर्तित किया जाना चाहिए?

Comments

यह इंगित करने के लिए कि यह तय करने के लिए हितधारक पर निर्भर है। एक बार पेचेक हस्ताक्षरकर्ता अपना निर्णय ले लेता है, बाकी सभी को इसके अनुरूप होना चाहिए।

मैं यह बहुत जोर से नहीं कहने जा रहा हूं, लेकिन मुझे लगता है कि अन्य ढांचे अधिक लचीले हैं। मेरी राय में (आसानी से) HTML को अक्षम करना किसी अन्य ढांचे (जैसे रेल) ​​पर जाने के बारे में सोचना शुरू करने का पर्याप्त कारण है।

— ऑस्ट्रोऑन

Answer 4

मेरी आखिरी नौकरी में, देवता एप्लिकेशन का निर्माण करेंगे और फिर इसे डिजाइनरों को सौंपेंगे ताकि वे इसे बना सकें जैसे कि सॉफ्टवेयर प्रोग्रामर का एक गुच्छा नहीं बना। :)

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

मैं प्रत्येक डिजाइनर के साथ बैठ गया और उन्हें सिखाया कि उनके स्थानीय बॉक्स पर वेब एप्लिकेशन कैसे स्थापित करें। मैंने उन्हें दिखाया कि इसे और सब कुछ कैसे चलाना है। मैंने समझाया कि स्क्रीन पर एस्प नियंत्रण कैसे प्रदान किए गए थे। और फिर हमने इसे ब्राउज़र में खोल दिया और एस्प कंट्रोल और जो प्रदान किया गया, उसके बीच के लिंक को देखने के लिए फायरबग का उपयोग किया।

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

ऐसा करने के बाद, मैंने डेवलपर्स के साथ एक बैठक की और उन्हें बताया कि उन्हें CssClass टैग का उपयोग करना चाहिए और यह सुनिश्चित करना चाहिए कि शैलियों को परिभाषित किया जा रहा है। और जो कुछ भी स्क्रीन पर गतिशील रूप से डाला जा रहा था, उसके लिए एक css वर्ग जुड़ा होना चाहिए b / c जिसे डिज़ाइनर जोड़ नहीं पाएंगे।

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

तो मेरा सुझाव डिजाइनरों के साथ बैठना और उन्हें दिखाना होगा कि पेज कैसे प्रस्तुत करता है। पेज को विच्छेदित करने के लिए फायरबग का उपयोग करें और यदि पृष्ठ बनता है तो कैसे गुजरें।

Answer 5

यहां कुछ उपयोगी दृष्टिकोण हैं जो मैंने डिजाइनरों के साथ अतीत में उठाए हैं जब उन्हें एक ASP.NET वेबफ़ॉर्म प्रोजेक्ट पर काम करना पड़ता है जिसे विकसित किया जा रहा है।

1. स्थानीय रूप से तैनात करें: डेवलपर्स स्थानीय रूप से तैनात परियोजना का एक मध्यवर्ती संस्करण प्रदान करते हैं। इससे दोनों का समय बचता है। डिजाइनर एक .aspx का अनुरोध करता है, लेकिन सर्वर कोड के बजाय प्रदान किए गए HTML के साथ इंटरैक्ट करता है। यह दृष्टिकोण डिजाइनर से सर्वर कोड को अमूर्त करता है। उसे यह जानने की आवश्यकता नहीं है कि HTML कैसे उत्पन्न की जाती है या क्लाइंट को कैसे javscript और cssफाइलें वितरित की जाती हैं। यह निश्चित रूप से मानता है कि डिजाइनर ब्राउज़र डीबगर्स / DOM इंस्पेक्टर के साथ कुशल हैं। डिजाइनर अपने सभी cssपरिवर्तनों को ब्राउज़र के अंदर लागू कर सकता है और बाद में उन्हें cssफ़ाइलों पर लागू कर सकता है।
2. मॉडल प्रदान करें: डिजाइनरों को HTML के साथ काम करने के लिए अधिक समझदार बनाने के लिए, उन्हें सर्वर नियंत्रण द्वारा प्रदान किए गए HTML के मॉडल के साथ प्रदान करें। वे उस HTML को उस बिंदु पर मोड़ सकते हैं जहां वे इसे पसंद करते हैं और सर्वर-साइड कार्यान्वयन में लागू किए जाने वाले परिवर्तनों का प्रस्ताव करते हैं। इसे जल्दी और अक्सर करने की आवश्यकता होती है , क्योंकि आप एक HTML संरचना के साथ समाप्त नहीं करना चाहते हैं जो क्लाइंट-साइड कार्यान्वयन पर निर्भर करता है और फिर डिजाइनर के लिए उस संरचना में परिवर्तन का प्रस्ताव करता है।

डिजाइनरों को सामान्य रूप से संभव के रूप में सर्वर साइड कोड के साथ कम स्पर्श बिंदु होने चाहिए, इसलिए जितना संभव हो उतना उन्हें इससे दूर रखें।

Answer 6

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

वे मार्कअप विकास और स्टाइलिंग के कुछ केंद्रीय सिद्धांतों का भी उल्लंघन करते हैं, बस इस तथ्य से कि, डिफ़ॉल्ट रूप से, ASP.NET आईडी विशेषता को लेता है, सीएसएस डिजाइनरों को उसी तरह कक्षाओं का उपयोग करने के लिए मजबूर करता है जिस तरह से आईडी का उपयोग किया जाना था, divs और नेस्टेड टैग के गहरे ढेर में तत्वों को रखना जो स्टाइलिंग को एक बुरे सपने की तरह सबसे सरल सिस्टम बना सकते हैं।

इन चीजों को देखते हुए, आपका रास्ता आसान नहीं है, क्योंकि मुझे लगता है कि एमवीसी के लिए फिर से लिखना लागत-या-समय-निषेधात्मक होगा।

क्या डिजाइनर को एक ऐसा वातावरण प्रदान करने का कोई तरीका है जिसमें वेब एप्लिकेशन को चलाया जा सके, ताकि वे वास्तविक समय में अपने CSS परिवर्तनों को देख सकें? जब मैं ASP.NET WebForms में डिज़ाइन का काम कर रहा होता हूं, तो मुझे यह पता चलता है कि मैं अपनी मशीन पर वेब ऐप को आग लगाने में सक्षम हो सकता हूं, CSS पर ट्विक करता हूं, और स्थानीय रूप से इसे देखता हूं कि ऐप को कैसे प्रभावित करता है।

एक विकल्प विशेष रूप से ASP.NET विकास के अनुरूप एक वर्चुअल मशीन स्थापित करना हो सकता है, जिसे डिज़ाइनर अपने वर्कस्टेशन से चला सकते हैं, इसलिए उन्हें अपने दो टूलसेट को मिलाना नहीं पड़ता है, और अगर वे देव में कुछ पेंच करने के लिए होते हैं- अंतरिक्ष, इसे हमेशा कार्यशील छवि से पुनः लोड किया जा सकता है।

हां, इसका मतलब है कि डिज़ाइनर को ऐप चलाने के लिए F5 दबाने का तरीका सीखना होगा। (या बस उन्हें एफ़टीपी तक पहुंच प्रदान करें जहां सीएसएस, जेएस और छवियां हैं, यहां तक ​​कि, एक परीक्षण वातावरण पर!) इसका मतलब यह भी है कि वे बहुत सारे बैक-एंड कोड देखेंगे, हालांकि यदि आप उन्हें बताएं बस अपनी .cs या .vb फ़ाइलों को अनदेखा करें, जो उन्हें घबराहट से बचाए रखने के लिए एक लंबा रास्ता तय करेंगी ... निश्चित रूप से, इसका मतलब है कि आपको यह सुनिश्चित करना होगा कि आप अपने कोडबेहाइंड फ़ाइलों से शैलियों को सेट करने जैसी चीजें नहीं कर रहे हैं। (लेकिन आप ऐसा नहीं करेंगे, क्या आप ऐसा करेंगे, जैसा कि डेटा और नज़दीकी से भी सही संबंध रखता है;)।

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

Comments

वास्तविक समय में सीएसएस परिवर्तनों को देखने के लिए, मैं सिर्फ फायरबग का उपयोग करता हूं। यह हर जगह काम करता है ... आप शायद Spidermonkey का भी उपयोग कर सकते हैं क्योंकि Firebug को विभिन्न पृष्ठों पर आपके परिवर्तन याद नहीं हैं

— Earlz

मैं यह मानने की तरह था कि कोई भी वेब डेवलपर अपने नमक के बराबर (यहां तक ​​कि केवल स्थिर HTML और CSS के साथ काम करता है) फायरबग जैसी किसी चीज़ का उपयोग कर रहा होगा, लेकिन यह विचार करने के लिए एक अच्छा बिंदु है ... फायरबग (या क्रोम की डेवलपर विंडो) को युग्मित करना एक परीक्षण सर्वर तक पहुंच के साथ, या इसे स्थानीय रूप से चलाने और उस के शीर्ष पर फायरबग का उपयोग करके, एक गतिशील "समायोजन" के लिए एक डिजाइनर को प्राप्त करने के लिए "आदर्श" वातावरण के लिए निकटतम चीज बनाता है जो उन्हें गतिशील साइटों के लिए करना पड़ता है।

— जेसन एम। बैटक स्नातक

Answer 7

आपको उन्हें एक साथ बात करने, एक दूसरे की जरूरतों और वरीयताओं को समझने की आवश्यकता है। यह एक "समस्या" है जिसे सॉफ्टवेयर और टूल द्वारा हल नहीं किया जा सकता है। दोनों पक्षों को खुश करने की कोशिश मत करो, यह कभी काम नहीं करेगा। उन्हें समझौता करने की आवश्यकता है - यह एक शादी की तरह है।

एक तरीका यह है कि f.ex की व्यवस्था करें। कार्यशालाएं जहां प्रत्येक पक्ष को यह समझाने का मौका मिलता है कि ऐसा क्यों है कि वे जो पसंद करते हैं उसे पसंद करते हैं। इस तरह की स्थितियों में अच्छा संचार हमेशा एक महत्वपूर्ण होता है। इनको इकट्ठा करना निवेश के रूप में देखा जा सकता है।

या बस कहा, समस्या संगठन-उन्मुख है, तकनीकी नहीं है और यही वह जगह है जहां आपको समाधान प्रदान करने की आवश्यकता है।

अन्य विकल्प वेतन बढ़ाने और उन्हें बंद करने के लिए कहना है (आमतौर पर एक अल्पकालिक समाधान ...)।

Comments

अंतिम पंक्ति = मजाक

— epistemex