ASP.NET Webform geliştiricileri ve web tasarımcıları: nasıl etkileşimde bulunulur?

ASP.NET Webforms geliştiricisiyim ve tasarımcılarla uğraşırken bazı sorunlarla karşılaşıyorum.

Tasarımcılar her zaman şikayetçi asp.net server controls. Sadece bir html dosyası var ve cssbunlarla gitmek için gerekli görüntülerle birlikte dosyalar oluşturuyorlardı . Bazen, tasarım aşaması önceden yapılırsa, ilgili css dosyalarıyla html dosyaları alıyorum, ancak daha sonra tasarımı aspxdosyalar ile entegre eden birçok sorunla karşılaşıyoruz (sever kontroller bir telerik kontrolleri ... vb).

Ne sormak istiyorum:

• Bu sorunların üstesinden nasıl gelirim? Tasarımcılar .net sunucu denetimleriyle ilgili sorunlar nedeniyle php- ve mvc geliştiricilerini tercih ederler. Tasarımcılar ile doğru şekilde nasıl etkileşim kuracağımı bilmem gerekiyor.
• Tasarımcılara .aspx sayfalarının işlenmiş (html sayfası) sağlamak için herhangi bir araç veya uygulama var mı? Bununla Visual Studio'da aspx yerine çalışma zamanında sayfa kastediyorum. Web Expression kullanıyorlar ama işlenmiş sayfayı HTML olarak da istiyorlar.

Eski Tasarımcı burada, Dev'i döndü ve ben de Web Kontrolleri hakkında işeyip inledi. Dürüst olmak gerekirse, bir tasarımcı için uygulamalarını bir .NET Geliştiricisinden daha iyi bir GridView özelliğine dönüştürmek için uygulamalarını ayarlaması daha ucuzdur, çünkü tasarımcı her TD'nin bir 'rel' etiketine (veya herhangi bir şeye) sahip olduğu konusunda ısrar etti.

Arseni Mourzenko'nun çok akıllıca işaret ettiği gibi, Webforms kullanma kararı, kodlamada bazı verimlilikler verirken HTML üzerindeki kontrolün bir kısmını sınırlayan bir şirket seçimidir. Şirket yeniden düşünmek istemiyorsa (ki bu sadece tasarımcıları memnun etmek için YAPMAMALIDIR), o zaman tasarımcıların bu gerçeği kabul etmeleri gerekir. İşte yapabilecekleri birkaç şey:

1) Herhangi bir şey için kimliklere bağlı olarak durun . İlk başta bu yanlış hissetse de, her şeyi sınıflarla (ve tabii ki mirasla) şekillendirdiğimde hayatın aslında çok daha kolay olduğunu gördüm. Her şeyden önce, tüm seçici ağırlıklarımı eşitledi. CSS mirasında, ID CLASS'ı koyar. Aslında her şeyin bir çocuk ve / veya sınıf seçici olması güzeldi ve özgüllük sırasını biraz daha basitleştirdi. JS katmanında da aynı şey, kimlik tabanlı seçicilerimi sınıf tabanlı olanlar için değiştirmem için SIFIR acı verdi.

2) Onlara RadioButtonLists ve CheckboxLists öğelerinin, Label = span, Panel = div ve diğer belirgin olmayan kontrol-html öğelerine dönüştüğünü öğretin . .NET'in bunları HTML'ye dönüştürme şekli beklediğimden biraz tuhaftı ve HTML'nin bu denetimlerden nasıl çıkacağını bildiğimde ekranlar oluşturmak benim için çok daha kolaydı.

3) Tasarımcılarına ham HTML ( ! Önemli ) değil, ASPX DOĞRUDAN yapmalarını sağlayın . Tasarımcılara GridViews, ListViews, vb. Temellerini öğretin. Anonim bir nesne koleksiyonunu Grid / ListView denetimine itmeleri için onlara bazı kod parçacıkları verin. Eğer CSS öğrenebilirlerse bu kodu kopyalayıp yapıştırmayı öğrenebilirler. Şimdi CSS ve JS işinde oldukça iyi olan VS Web Express'in ücretsiz sürümünü kullanabilirler. Bu kukla web projeleri, tasarımcılara bazı kontrollere girme şansı verecek, ardından nasıl oluşturulduklarını görmek için Kaynağı Görüntüle.

4) FORM etiketinin .NET'te nasıl kullanıldığını açıklayın . Bunu daha önce unuttum, ancak tasarımcının alışması gereken başka bir şey, genellikle tek bir FORM etiketinin tüm sayfayı sarmasıdır. Bu, form denetimlerinin davranış biçimini değiştirir ve FORM etiketlerini gerçekten garip yan etkiler olmadan iç içe yerleştiremezsiniz. Tasarımcıların bunu anladığından emin olun, aksi takdirde form HTML'si WebForms'a dönüştürmek için bir kabus olacaktır.

5) Temalar ve Cilt'ten uzak durun . .NET çerçevesi bir uygulamada stil kontrollerine yardımcı olmak için bu araçlara sahip olsa da, normal Web Tasarımcıları için tıknaz ve tuhaflar ve onları asla zaman ayırmaya değer bulmadım. CSS'de tecrübeli olmayan geliştiriciler için güzel bir araç gibi görünüyorlar, ancak sadece tasarımcıları yavaşlatacaklar. Tasarımcıların doğal ortamlarında (html & css dosyaları) çalışmasına izin verin ve daha mutlu ve daha üretken olacaklar.

6) "prototip" projeleri site çözümlerinizde tutun . Geliştiricilerin her zaman kodlama hedefleri olduğundan emin olmak için, tasarımcıların gerçek çözümünüzde yalnızca ASPX sayfalarını gerçek geliştiriciler tarafından korunmasını ve dokunulmamasını sağlamak için sahte bir web projesi oluşturmalarını sağlayın. Bu, tasarımcıların prototiplerine, geliştiricilerin nasıl çalıştığını kontrol etmek için gerçek projeyle aynı çözümde geri bakabilecekleri anlamına gelir ve geliştiriciler, çalışmalarının tasarımcıların niyetiyle eşleştiğinden emin olmak için prototipi istedikleri zaman çalıştırabilir.

Son olarak, Devs'inizi yeniden eğitmeye hazır değilseniz, MVC'ye dönüştürmek için herhangi bir şikayete karşı koyun. MVC'yi kişisel olarak seviyorum, ancak bir sürü WebForms bilgisine sahip bir ekibiniz varsa, bunu sebepsiz yere atmayın. Uygulamalarınız ViewState sorunları, SEO sorunları veya erişilebilirlik sorunları yaşıyorsa, MVC'ye kesinlikle sert bir görünüm verin. Ancak MVC'de WebForms geliştiricilerini eğitmek, Tasarımcılara Web Denetimlerini nasıl kullanacaklarını eğitmekten çok daha fazla zaman alacaktır.

Günün sonunda, anlaşmadan önce bir saat boyunca o lanet GridView'de küfür etsem bile, WebForms'da kişisel olarak çalışamayacağım TASARIM YOKTUR.

Tasarımcılara .aspx sayfalarının işlenmiş (html sayfası) sağlamak için herhangi bir araç veya uygulama var mı?

İfadeyi Unut (Hiç hoşuma gitmedi). Onlara Visual Studio'nun (Web Developer Express) ücretsiz sürümünü edinin. Sahip olduğunuz kaynak kontrol çözümüne bağlanabilir ve tasarımcıların ASPX sayfalarını çalıştırmasına ve oluşturulan HTML'yi bir tarayıcıda görmesine izin verir. CSS ve JS takımları eskisinden çok daha iyi ve Web Essentials gibi uzantılara göre hazırlanmış bazı harika araçlar var. CSS kurallarının VS arabiriminde satıcıya özgü tüm sapmalarına, renk seçicilerine ve paletlerine tek tıklamayla dönüştürülmesi, görüntülerin css dosyalarına 1 tıklama gömülmesi, 'LESS' CSS dönüşümleri (CSS'de 'kodlayabilirsiniz'), F12 JavaScript'te 'Şuraya Git', artı gerçek zeka ve çok daha fazlası. Şimdi tasarımcılar için bir hazine, FYI,

Sorunlarınıza bir çözüm var, ancak MVP'de bir tasarım deseni değişikliği içeriyor . Bu, başlamadan önce ciddi şekilde düşünülmesi gereken, ön plana çıkan bir yatırımdır.

Temel olarak, yaşadığınız sorunlar yeni değildir. Kısacası, görünümün desteklediği veri modelini tanımlayan arabirim yoluyla bir görünüm soyutlaması getirmeniz gerekir.

Deseni bir yaşam örneği olarak görmek mantıklı olan çok kapsamlı bir konudur. Bu örneği durumunuz için oldukça bilgilendirici bulabilirsiniz - MVP Desenli Daha İyi Web Formları .

Düzenleme: Yukarıdaki öneri takip etmek için çok pahalı (zaman ve kaynaklar açısından) ise, kesinlikle tasarımcı ile daha yakın çalışmak için tavsiye ediyorum . Sorunlarınızı bir ekip içinde iletmenin, (tasarımcının ve geliştiricinin) çalışmanızdaki engelleri çözmeye büyük ölçüde yardımcı olması gerektiğine inanıyorum . Bu bir ekip çalışması ve işin gerçekleştirilmesi için tüm engelleri kaldırmak için sorunların iyi işbirliği, bir ekip olarak bir projede başarılı olmanın yoludur ! Bu, projemizde yaptığımız bir şey.

ASP.NET, oluşturulan HTML kodunu soyutlayan bir çerçevedir. Bu , ASP.NET denetimleri tarafından oluşturulan herhangi bir şeyi yeniden yazmak için yeterli bütçeniz olmadığı sürece, belirli bir HTML kodunu bir ASP.NET uygulamasında yeniden oluşturmanız istenemeyeceği anlamına gelir .

Karar vermek paydaşların sorumluluğundadır: ASP.NET kontrollerini güçlü noktaları ve dezavantajları ile kullanırsınız veya mevcut HTML'nin maliyetini binlerce dolar artırarak manuel HTML'ye (veya ASP.NET MVC'ye) geçersiniz. .

HTML'yi bu bağlamda özelleştirememe, diğerleri gibi bir kısıtlamadır. Tasarımcılar işlerinde bu teknik kısıtlamayı göz önünde bulundurmalıdır. Durum, tasarımcının size bir metnin tam yazı tipinde tam boyutta görüntülenmesi gerektiğini söyleyip söylemeyeceğine çok benziyor: bu bir web desteği, yazdırılmıyor, bu da metnin boyutunun değişeceği anlamına geliyor.

Araçlara gelince, düz HTML'yi bir ASP.NET şablonuna dönüştürecek araçların farkında değilim. Belirli bir tablonun belirli bir ASP.NET denetimine dönüştürülmesi gerektiğini nasıl tahmin edebilirim?

Son işimde, geliştiriciler uygulamayı oluşturacak ve daha sonra onu tasarımcılara ileteceklerdi, böylece bir sürü yazılım programcısının yapmadığı gibi görünmelerini sağlayabilirlerdi. :)

Bu sürece ilk başladığımızda, geliştiriciler ve tasarımcılar arasında ileri geri birçok şey vardı. Kendilerine verilen sayfaları anlamadılar. Cennet dinamik olarak bir sayfa oluştursaydık yasak! Burada tarif ettiğiniz durumla hemen hemen aynıydı.

Her tasarımcıya oturdum ve web uygulamasını yerel kutularına nasıl kuracağımı öğrettim. Onlara nasıl çalıştırılacağını ve her şeyi gösterdim. Asp kontrollerinin ekranda nasıl oluşturulduğunu açıkladım. Ve sonra tarayıcıda açtık ve asp kontrolleri ve oluşturulanlar arasındaki bağlantıyı görmek için kundakçı kullandık.

Bu onlara çok yardımcı oldu. Bir kez görebildiklerinde ve kutularında çalıştırıp tasarım araçlarını stillerle oynamak ve oynamak için kullandıklarında, hayatlarını kolaylaştırdı.

Bunu yaptıktan sonra, geliştiricilerle bir toplantı yaptım ve CssClass etiketini kullanmaları ve stillerin tanımlandığından emin olmaları gerektiğini söyledim. Ve dinamik olarak ekrana konulan herhangi bir şey, tasarımcıların ekleyemeyeceği bir css sınıfının ona bağlı olması gerekir.

Bu bir süreçti. Her iki tarafın da düzenlemeye alışması biraz zaman aldı. Ancak iletişim hatlarını açtı. Tasarımcılar kullanılan kontrollerden şikayet etmek yerine çeşitli unsurlara stil eklenmesini talep edebildiler.

Benim önerim tasarımcılarla oturup onlara sayfanın nasıl işlediğini göstermek olacak. Sayfayı incelemek ve oluşturulduysa sayfanın nasıl ilerlediğini görmek için kundakçı kullanın.

İşte, tasarımcılar ile geliştirilmekte olan bir ASP.NET WebForms projesi üzerinde çalışmak zorunda kaldıklarında, geçmişte kullandığım bazı yararlı yaklaşımlar.

1. Yerel Olarak Dağıt: Geliştiriciler, yerel olarak dağıtılan projenin bir ara sürümünü sağlar. Bu her ikisine de zaman kazandırır. Tasarımcı bir .aspx ister, ancak sunucu kodu yerine oluşturulan HTML ile etkileşime girer. Bu yaklaşım, tasarımcıdan sunucu kodunu soyutlar. HTML'nin nasıl oluşturulduğunu veya javscript ve cssdosyalarının istemciye nasıl teslim edildiğini bilmesine gerek yoktur . Bu, elbette tasarımcıların tarayıcı hata ayıklayıcıları / DOM denetçisi ile yetenekli olduğunu varsayar. Tasarımcı tüm cssdeğişikliklerini tarayıcıya uygulayabilir ve daha sonra bunları cssdosyalara uygulayabilir .
2. Model Sağlayın: Tasarımcıların HTML ile çalışmasını sağlamak için, sunucu denetimi tarafından oluşturulan bir HTML modeli sağlayın. Bu HTML'yi istedikleri noktaya ayarlayabilir ve sunucu tarafı uygulamasında uygulanacak değişiklikleri önerebilirler. Bunun , erken ve sık sık yapılması gerekir , çünkü istemci tarafı uygulamasının dayandığı bir HTML yapısıyla sonuçlanmak istemezsiniz ve daha sonra tasarımcının bu yapı üzerinde değişiklikler önermesi gerekir.

Tasarımcılar genellikle sunucu tarafı koduyla mümkün olduğunca az temas noktasına sahip olmalıdır, bu yüzden mümkün olduğunca onlardan soyutlayın.

Hibrit bir geliştirici olarak, kendim (hem arka uç hem de ön uç rollerinde, genellikle birlikte çok fazla iş yaptıktan sonra), ASP.NET WebForms modelinden de uzun süredir hoşlanmıyorum ... tasarım itici güç, web geliştirmeyi demokratikleştirmek için kolay, sürükle ve bırak tasarım araçları sağlamaktı (Visual Basic'in uygulama programlamayı CS-major olmayanlar tarafından erişilebilir hale getirdiği gibi), vatansız çevre (web) jambon teslim ve zorla (oh ViewState, senden nasıl nefret ediyorum!).

Ayrıca, ASP.NET'in varsayılan olarak ID özniteliğini devralarak CSS tasarımcılarını sınıfları kimliklerin kullanılması gerektiği gibi kullanmaya zorlamasıyla, biçimlendirme geliştirme ve stilin bazı temel ilkelerini ihlal ediyorlar. kontrolleri en basit sistemlerin dışında bir kabus haline getirebilecek derin div yığınları ve iç içe etiketlerdeki katman öğeleri.

Bu şeyler göz önüne alındığında, MVC için bir yeniden yazmanın maliyet veya zaman kısıtlayıcı olacağını varsayacağınız yolunuz kolay bir yol değildir.

Tasarımcıya CSS değişikliklerini gerçek zamanlı olarak görebilmeleri için web uygulamasını çalıştıracakları bir ortam sağlamanın bir yolu var mı? ASP.NET WebForms'da tasarım çalışması yaparken, web uygulamasını kendi makinemde çalıştırabilmenin, CSS'de ince ayarlar yapmanın ve uygulamayı nasıl etkilediğini görmek için yerel olarak çalıştırmanın paha biçilmez olduğunu düşünüyorum.

Bir seçenek, tasarımcının iş istasyonlarından çalıştırabileceği ASP.NET geliştirmesine özel olarak tasarlanmış bir sanal makine kurmak olabilir, bu nedenle iki araç setini karıştırmak zorunda kalmazlar ve geliştiricideki bir şeyi bozarlarsa alan, her zaman çalışan bir görüntüden yeniden yüklenebilir.

Evet, bu, tasarımcının uygulamayı çalıştırmak için F5'e nasıl basacağını öğrenmesi gerektiği anlamına gelir. (Ya da sadece test ortamında CSS, JS ve görüntülerin olduğu dizinlere FTP erişimi verin!) Ayrıca, eğer onlara söylerseniz, bir çok arka uç kodu görecekleri anlamına gelir. sadece .cs veya .vb dosyalarınızı görmezden gelin, bu onları paniklemekten korumak için uzun bir yol kat edecektir ... Tabii ki, bu, kod arkası dosyalarınızdan stil ayarlama gibi şeyler yapmadığınızdan emin olmanız gerektiği anlamına gelir. (ancak bunu yapmazsınız, öyle olur, çünkü bu verileri ve görüşü çok yakından bağlar, değil mi?).

Siteniz farklı CSS ve JS dosyaları ile iyi yapılandırılmışsa ve işaretlemeye zorlanan çok fazla satır içi stil değilse, işlerinin çoğunu <%%> alanlarından kaçınarak gerçekleştirebilirler. Öte yandan, statik HTML / CSS'lerini dinamik bir uygulama için çalışan bir şeye çevirmeye çalışırken tasarımcıya geçmeniz gerekenler için biraz daha fazla takdir verebilir.

Onları birlikte konuşturmalı, birbirlerinin ihtiyaçlarını ve tercihlerini anlamalısınız. Yazılım ve araçlar tarafından çözülemeyen bir "sorun". Her iki tarafı da memnun etmeye çalışmayın, bu asla işe yaramaz. Taviz vermeleri gerekiyor - bu bir evlilik gibi.

Bunun bir yolu f.ex. her bir tarafın neden tercih ettiklerini tercih ettiklerini açıklamak için fırsat buldukları atölye çalışmaları. Böyle durumlarda iyi iletişim her zaman anahtardır. Bu gibi toplama yatırım olarak görülebilir.

Veya basitçe söylemek gerekirse, sorun teknik değil organizasyona yöneliktir ve çözüm sağlamanız gereken yer burasıdır.

Diğer seçenek ödemeyi arttırmak ve onlara kapanmalarını söylemektir (genellikle kısa vadeli bir çözüm ...).