我正在进入ASP.NET(C# - 我知道这对于这个特定的问题并不重要,但完全披露和所有这些),虽然我喜欢这种asp:风格的控件省了很多繁琐的HTML制作,我经常对某些行为感到沮丧.昨晚我在使用Master Pages时遇到了一个问题:我
还有其他问题 - 我注意到当你自动填充DataGrid时,它会在结果表中添加我不一定想要的属性.
我知道当你依靠一个框架来接管你的一些繁琐的职责时,你必须接受一定数量的"约定优于配置",但这些情况下的"约定"并不是任何既定的约定,而是不必要的额外.我知道为什么 ID会添加前缀,但我应该能够调整并关闭这样的东西,特别是因为,作为一个网络标准传播者,我不会在单个页面中复制HTML id.
所以这里的问题是那些比我更经验丰富的ASP.NET开发人员:在开发和部署应用程序的经验中,你如何利用这些控件？您是否发现自己回归硬编码的HTML？你用混合物吗？我不想在这些控件中围绕特殊怪癖设计我的HTML,但是,如果可能的话,我想在可能的情况下利用它们.
什么是男孩要做？
亲身,
我认为标准的ASP.NET控件适用于内部的东西 - 在这种情况下,快速和肮脏是好的.但是,我曾与一位同时也是设计师的Web开发人员合作,他拒绝使用ASP.NET控件,只使用HTML代码并在需要时添加runat ="server"标签.这更多是因为他想知道他的HTML究竟是如何呈现的,当时无论如何,一些ASP.NET控件都无法实现标准兼容性.
我坐在中间的某个地方 - 在适当的地方使用HTML,而不是在不适用时.使用CSS控件适配器,您可以最好地兼顾两个世界
我真的很欣慰地看到一些意见在这里同意我自己:ASP.NET作为模板语言非常差.
我只是想反驳一下这里提出的几个专业点(火焰服!):
戴夫沃德提到身份证的碰撞 - 这是事实,但我处理得有多糟糕.我宁愿看到xpath或深度css选择器引用的节点,而不是使ID无效,除非延迟到像clientID这样的ASP.NET内部 - 它只是让编写CSS和JS变得更加毫无意义.
Rob Cooper谈论控件如何替代HTML,所以一切都很好(释义,请原谅Rob) - 好吧,这不好,因为他们采用现有的,理解得很好的语言并说"不,你必须按我们的方式做事现在",他们的方式执行得很差.例如asp:panel在一个浏览器中呈现一个表,在另一个浏览器中呈现一个div!没有文档或执行,登录控件(以及许多其他标记)的标记是不可预测的.你是如何让设计师针对它编写CSS的呢？
Espo写道如果平台更改了html,控件如何为您提供抽象的好处 - 这显然是循环的(它只是因为平台正在改变而改变,如果我只是在那里拥有自己的HTML,则不需要)和实际上会产生问题.如果控件将随着更新再次改变,我的CSS应该如何应对？
护理人员会说"是的,但你可以在配置中改变它",或者讨论覆盖控件和自定义控件.那我为什么要这么做？用于修复其中一些问题的css友好控件包除了它的非语义标记之外什么都没有解决ID问题.
使用webform应用程序开箱即用MVC(抽象概念,而不是3.5实现)是不可能的,因为这些控件可以紧密地绑定视图和控件.传统的网页设计师现在有一个进入障碍,因为他必须参与服务器端代码来实现以前的CSS和JS的独立领域.我同情这些人.
我非常同意Kiwi的观点,即控件允许对特定配置文件的应用程序进行一些非常快速的开发,并且我接受无论出于何种原因某些程序员发现HTML令人不快,并且进一步说明ASP.NET的其他部分给你带来的好处,这需要这些控制,可能是物有所值.
然而,我对失去控制感到不满,我觉得处理代码隐藏的类,样式和脚本等事情的模型是一个错误的退步步骤,我进一步认为有更好的模板模型(微格式和xslt的实现)虽然用这些替换控件是非平凡的,但这个平台).
我认为ASP.NET可以从LAMP和rails世界中的相关技术中学到很多东西,直到那时我希望能够在可以的情况下使用3.5 MVC.
(对不起那么久)
京公网安备 11010802040832号 | 京ICP备19059560号-6 