控件与标准HTML
我正在使用ASP.NET(CI知道这个特定的问题无关紧要，但是要全面披露等等)，尽管我喜欢" asp："样式的控件为我节省了很多繁琐的HTML-手工制作时，我经常对某些行为感到沮丧。我昨晚在使用母版页时遇到了一个问题：我的<asp：BulletedList ID =" nav">转换为HTML后变成了<ul id =" ct100_nav">。
还有其他问题-我注意到，当我们自动填充DataGrid时，它会向结果表添加我不一定要在那里存在的属性。
我知道，当我们依靠框架来接管一些繁琐的工作时，必须接受一定数量的"配置约定"，但是在这些情况下的"约定"并没有那么多已建立的约定，但不必要的额外功能。我知道ID为什么要添加前缀，但是我应该能够调整并关闭类似的功能，特别是因为作为Web标准的传播者，我无论如何都不会在单个页面中重复HTML ID。
因此，这里的问题是那些比我更有经验的ASP.NET开发人员：在我们开发和部署应用程序的经验中，我们如何利用这些控件？我们是否发现自己重新使用了硬编码的HTML？我们是否使用混合？我不想围绕这些控件中的特质古怪设计我的HTML，但是，如果可能的话，我想在可能的情况下利用它们。
男孩要做什么？
解决方案
回答
我也正在冒险进入ASP.NET，并且也遇到了类似的挫折。.但是，我们很快就习惯了。我们只需要记住，没有繁琐的HTML编写的原因是因为ASP.NET控件可以为我们完成所有这些工作。
在某种程度上，我们可以控制/调整这些内容，即使这意味着继承控件并从那里调整HTML输出。
在过去，我不得不这样做，因为某些控件默认情况下不会通过在此处和此处放置一些额外的标记来默认通过W3C验证，因此我只是根据需要进行覆盖和编辑(实际上是几分钟的修复)。
我想说的是了解控制系统的工作原理。然后自己敲几个门，这确实帮助我了解了引擎盖下发生的事情，因此，如果遇到任何问题，我有一个解决之道。
回答
至于服务器控件上的ID：我们可以通过访问ClientID找到将要写入浏览器的实际ID。这样，我们可以结合服务器端og客户端脚本，而不必硬编码_id =" ct100_nav" _
我总是尝试使用包含的控件而不是" hacking" HTML，因为如果以后有更新或者某些改进，只需替换框架，我的所有代码仍然可以工作，而无需更改任何HTML。
希望这可以帮助
回答
如果ASP.NET添加的ID前缀是我们以后使用JS或者其他方式访问它们的问题，那么我们将拥有.ClientID属性服务器端。
如果由ASP.NET增加开销，则应考虑在ASP.NET MVC(仍为预览)中完全控制所发出的html。
我要迁移到MVC，因为我也不喜欢添加的所有内容...。
回答
@布莱恩，
是的！我们几乎可以控制所有行为。考虑考虑创建自定义控件(共有三种类型)。我最近在这里提出了对它们的概述。
我强烈建议我们检查一下，对我无休止:)
回答
亲自，
我认为标准ASP.NET控件适合内部内容的快速处理，而在那种情况下则很好。但是，我曾经和一位同时还是设计师的Web开发人员一起工作，他拒绝使用ASP.NET控件，只使用HTML代码，并在需要时添加runat =" server"标签。这更多是因为他想确切地知道他的HTML将如何呈现，而且无论如何，在某些时候，某些ASP.NET控件不会呈现为符合标准。
我坐在中间的某个地方，在适当的地方使用HTML，而不是在不适当的地方。我们可以使用CSS控件适配器来兼顾两者
回答
我认为这里的大多数答案都是从设计师的角度出发的。在中小型项目中，同步代码和CSS / HTML并使它们符合标准且干净整洁似乎是一项开销。设计人员的方法是完全控制呈现的HTML。但是有很多方法可以在ASP.NET中进行完全控制。对我来说，在aspx / ascx文件中具有所需的HTML是最不可扩展且最脏的方法。如果要通过CSS设置控件样式，则始终可以通过CssClass属性在服务器端设置类。如果要通过JS访问它们，则可以在服务器端再次发出具有正确ID的JS。这提供的唯一缺点是开发人员和设计师必须紧密合作。无论如何，这在任何大型项目中都是不可避免的。但是ASP.NET提供的优势远远超过了这些困难。
不过，如果我们希望使用符合标准的HTML，外观支持和其他功能来控制呈现的标记，则始终可以使用第三方控件。
回答
HTML使用此类ID进行呈现，因为它的ASP.NET防止ID冲突的方式。每个容器控件(例如母版页或者向导控件)都将在其子级ID之前添加" ID_"。
对于项目符号列表，ListView提供了一个很好的中间立场。我们仍然可以将其绑定到数据源，但是它可以使我们对呈现的HTML进行更严格的控制。 Scott Gu在这里对ListView有一个很好的介绍：
http://weblogs.asp.net/scottgu/archive/2007/08/10/the-asp-listview-control-part-1-building-a-product-listing-page-with-clean-css-ui。 aspx
回答
正如Dave Ward已经提到的那样，"这是ASP.NET防止ID冲突的方式。"
一个很好的例子是，如果我们试图将控件放入自定义控件中，然后在转发器中使用该自定义控件，以便该自定义控件的HTML将为页面多次输出。
正如其他人提到的那样，如果我们需要访问javascript的控件，请使用ClientScript属性，该属性将使我们可以访问ClientScriptManager并以这种方式将脚本注册到该页面。确保在编写脚本时使用要尝试引用的控件上的ClientID属性，而不是仅键入控件的ID。
回答
简短的答案是，除非有充分的理由，否则永远不要使用标准HTML控件的asp：...版本。
由于大多数ASP.NET书籍都涵盖了初级控件，因此初级开发人员经常会迷上这些控件的使用，因此假定它们必须更好。他们不是。在这一点上，经过每天8年的ASP.NET开发，我只能想到2或者3种情况下使用asp实际上是有意义的：...对标准HTML控件的INPUT控制。
回答
实际上，我很高兴看到这里的一些观点与我自己的观点一致：ASP.NET作为模板语言非常差。
我只想反驳在此提出的几个要点(打火仗！)：
戴夫·沃德(Dave Ward)提到ID冲突是对的，但是我的处理方式很糟糕。我更希望看到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实现)是不可能的，因为这些控件紧密地绑定了视图和控件。对于传统的Web设计人员而言，现在进入门槛很高，因为他必须参与服务器端代码才能实现以前属于CSS和JS的单独领域。我同情这些人。
我非常同意Kiwi的观点，即控件可以对具有特定配置文件的应用进行非常快速的开发，并且我接受出于某些原因，某些程序员认为HTML令人不快，而且ASP.NET其他部分为我们带来的优势，需要这些控件，可能是值得的。
但是，我很讨厌失去控制，我觉得处理代码中的类，样式和脚本之类的模型是错误的倒退，而且我进一步感觉到有更好的模板模型(实现微格式和xslt用于这个平台)，尽管用这些控件代替控件并非易事。
我认为ASP.NET可以从LAMP和Rails世界的相关技术中学到很多东西，直到那时，我希望能与3.5 MVC一起工作。
(很久很抱歉</ rant>)
回答
如果要对呈现的HTML进行大量控制，请查看ASP.NET MVC。
