Dev曾经是这里的前设计师,我曾经对Web控件感到不满和抱怨。坦率地说,对于设计师来说,调整其实践要比让.NET Developer深入研究GridView的自定义实现便宜得多,因为设计师坚持认为每个TD都有一个“ rel”标签(或其他任何东西)。
正如Arseni Mourzenko非常明智地指出的那样,决定使用Webforms是公司的选择,它限制了对HTML的某些控制,同时还提高了编码效率。除非公司愿意重新考虑(他们不应该只是为了取悦设计师),否则设计师需要接受这种现实。他们可以做的几件事:
1)停止根据ID进行操作。尽管起初觉得这是错误的,但我发现当我用类(当然还有继承)来样式化所有内容时,生活实际上要容易得多。首先,它均衡了我所有选择器的权重。在CSS继承中,ID胜过CLASS。让所有内容都成为孩子和/或类选择器确实很不错,并且使确定特异性的顺序更加简单。在JS层中也是如此,这让我很痛苦,无法将基于ID的选择器换成基于类的选择器。
2)教给他们RadioButtonLists和CheckboxLists转换成什么,以及Label = span,Panel = div和其他非显而易见的HTML控件。.NET将这些内容呈现为HTML的方式比我预期的要怪,而且当我知道HTML将如何从这些控件中提取出来时,对于我来说创建屏幕要容易得多。
3)让他们直接在ASPX中做设计师,而不是原始HTML(!important)。教给设计人员GridViews,ListViews等的基础知识。给他们一些代码片段,以将匿名对象集合推送到Grid / ListView控件中。如果他们可以学习CSS,那么他们可以学习复制粘贴此代码。他们可以使用VS Web Express的免费版本,该版本现在非常擅长CSS和JS的工作。这些虚拟Web项目将使设计人员有机会输入一些控件,然后单击“查看源代码”以查看它们的呈现方式。
4)解释.NET中如何使用FORM标签。早些时候忘记了这一点,但是设计人员必须习惯的另一件事是,通常,单个FORM标记会包裹整个页面。这改变了表单控件的行为方式,并且您不能嵌套FORM标签而没有真正奇怪的副作用。确保设计人员理解这一点,否则他们的表单HTML将成为WebForms的噩梦。
5)远离主题和皮肤。尽管.NET框架提供了这些工具来帮助跨应用程序进行样式控制,但它们对于普通的Web Designer而言既笨拙又怪异,我从来没有发现它们值得我花时间。对于不精通CSS的开发人员而言,它们似乎是一个不错的工具,但只会减慢设计人员的工作速度。让设计人员在自然环境中工作(html和css文件),他们将更快乐,更高效。
6)在您的站点解决方案中保留“原型”项目。为了确保开发人员始终有针对的目标,请设计人员在您的实际解决方案中创建一个虚假的Web项目,以保留他们的仅ASPX页面,而不让真正的开发人员使用。这意味着设计人员可以在与真实项目相同的解决方案中回顾他们的原型,以检查开发人员的工作方式,并且开发人员可以随时运行原型以确保其工作符合设计者的意图。
最后,除非准备好重新培训开发人员,否则请抵制所有投诉以转换为MVC。我个人很喜欢MVC,但是如果您有一个拥有大量WebForms知识的团队,请不要无缘无故地扔掉它。如果您的应用程序存在ViewState问题,SEO问题或可访问性问题,那么绝对可以使MVC看上去更加困难。但是,在MVC上培训WebForms开发人员比培训设计人员如何使用Web控件要花费更多时间。
归根结底,即使我最终在那个令人毛骨悚然的GridView上发誓要花一个小时再弄清楚它,但我仍然无法进行跨设计的工作,我无法亲自在WebForms中进行工作。
是否有任何工具或应用程序可为设计人员提供.aspx页的呈现(html页)?
忘了表情(我从未喜欢过)。为他们提供Visual Studio的免费版本(Web Developer Express)。它可以连接到您拥有的任何源代码控制解决方案中,并使设计人员可以运行ASPX页面并在浏览器中查看呈现的HTML。CSS和JS工具比以前要好得多,并且有一些很棒的工具被嵌入到Web Essentials等扩展中。一键式将CSS规则转换为所有特定于供应商的偏差,在VS界面中进行颜色选择器和调色板,一键式将图像嵌入到css文件中,“无需” CSS转换(您可以在CSS中进行“编码”), F12在JavaScript上“导航至”,再加上真正的智能,还有更多。现在,FYI是设计师们的宝库,