控件与标准 HTML
https://stackoverflow.com/questions/22084
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian题
我正在研究 ASP.NET（C# - 我知道这对于这个特定问题并不重要，但全面披露等等），虽然我喜欢 asp:- 风格的控件让我省去了很多繁琐的 HTML 制作工作，我经常对某些行为感到沮丧。昨晚我在使用母版页时遇到了一个问题：我的 <asp:BulletedList ID="nav">, ，当转换为 HTML 时，变成 <ul id="ct100_nav">.
还有其他问题 - 我注意到当您自动填充 DataGrid 时，它会向结果表中添加我不一定想要的属性。
我知道，当您依赖框架来接管一些繁琐的职责时，您必须接受一定数量的“约定优于配置”，但这些情况下的“约定”并不是任何既定的约定，而是不必要的额外内容。我知道 为什么 ID 添加了前缀，但我应该能够调整并关闭类似的功能，特别是因为，作为一名 Web 标准传播者，我无论如何都不会在单个页面中重复 HTML id。
所以这里的问题是针对那些比我更有经验的 ASP.NET 开发人员：根据您开发和部署应用程序的经验，您如何利用这些控制？您是否发现自己又求助于硬编码 HTML？你用混合物吗？我不想围绕这些控件中的特殊怪癖来设计我的 HTML，但是，如果可能的话，我希望尽可能地利用它们。
男孩该做什么？
解决方案
亲自，
我认为标准 ASP.NET 控件非常适合内部使用 - 在这种情况下快速和肮脏是好的。但是，我曾经与一位 Web 开发人员一起工作，他也是一名设计师，他拒绝使用 ASP.NET 控件，只使用 HTML 编写代码，并在需要时添加 runat="server" 标记。这更多是因为他想确切地知道他的 HTML 将如何呈现，而且无论如何，当时某些 ASP.NET 控件无法呈现为符合标准。
我处于中间位置——在适当的时候使用 HTML，在不适当的时候不使用 HTML。您可以两全其美 CSS 控制适配器
其他提示
事实上，看到这里的一些观点与我自己的观点一致，我感到很欣慰：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 实现），因为这些控件将视图和控件紧密地绑定在一起。现在传统网页设计师存在进入障碍，因为他必须参与服务器端代码来实现曾经是 CSS 和 JS 的独立领域。我同情这些人。
我非常同意 Kiwi 的观点，即控件允许对特定配置文件的应用程序进行一些非常快速的开发，并且我接受无论出于何种原因，一些程序员发现 HTML 令人不快，并且进一步认为 ASP.NET 的其他部分给您带来的优势，这需要这些控制， 可能 值得这个价钱。
然而， 我 我对失去控制感到不满，我觉得在代码隐藏中处理类、样式和脚本之类的模型是一种错误的倒退，而且我进一步觉得有更好的模板模型（针对这个平台的微格式和 xslt 的实现）尽管用这些替换控件并非易事。
我认为 ASP.NET 可以从 LAMP 和 Rails 世界的相关技术中学到很多东西，在那之前我希望尽可能地使用 3.5 MVC。
（抱歉这么久了</rant>）
简短的回答是你永远不应该使用 asp:...标准 HTML 控件的版本，除非您有充分的理由。
初级开发人员经常沉迷于使用这些控件，因为大多数 ASP.NET 书籍都介绍了这些控件，因此人们认为它们一定更好。他们不是。到目前为止，经过 8 年的日常 ASP.NET 开发，我只能想到 2 或 3 个使用 asp 确实有意义的情况：...对标准 HTML 的 INPUT 控制。
至于服务器控件上的 ID：您可以通过访问ClientID找到将要写入浏览器的实际ID。这样您就可以结合服务器端和客户端脚本，并且仍然不必硬编码 _id="ct100_nav"_
我总是尝试使用包含的控件而不是“破解”HTML，因为如果以后有更新或一些改进，我的所有代码仍然可以通过替换框架来工作，并且我不必更改任何 HTML。
希望这可以帮助
@brian，是的！你几乎可以控制所有的行为..考虑创建自定义控件（共有三种类型）。我最近在我的问题中概述了它们 这里.
我会 强烈地 建议检查一下，对我帮助无穷:)
我也在探索 ASP.NET，也遇到过类似的挫折。不过，你很快就会习惯的。你只需要记住， 您无需进行繁琐的 HTML 制作的原因是 ASP.NET 控件为您完成了这一切.
在某种程度上，您可以控制/调整这些东西，即使这意味着继承控制并调整 HTML 输出。
过去，我不得不这样做，某些控件默认情况下通过在各处放置一些额外的标记而未通过 W3C 验证，因此我只是根据需要进行覆盖和编辑（实际上需要几分钟的修复）。
我想说的是了解控制系统是如何工作的。然后自己把一些东西放在一起，这确实帮助我了解了幕后发生的事情，所以如果我遇到任何问题，我知道该去哪里。
HTML 使用此类 ID 进行呈现，因为它是 ASP.NET 防止 ID 冲突的方法。每个容器控件（例如母版页或向导控件）都将在其子 ID 上添加“ID_”。
对于项目符号列表，ListView 提供了一个很好的中间立场。您仍然可以将其绑定到数据源，但它使您可以更严格地控制呈现的 HTML。Scott Gu 在这里对 ListView 有一个很好的介绍：
如果 ASP.NET 添加的 ID 前缀对您稍后使用 JS 或其他方式访问它们来说是一个问题......您有 .ClientID 属性服务器端。
如果 ASP.NET 添加了开销，您应该考虑 ASP.NET MVC（仍为预览版），您可以完全控制发出的 html。
我正在转向 MVC，因为我也不喜欢添加所有这些东西......
我认为这里的大多数答案都采取了设计师的观点。在中小型项目中，同步代码和 CSS/HTML 并使它们符合标准且干净似乎是一项开销。设计者的方法是完全控制渲染的 HTML。但有很多方法可以在 ASP.NET 中实现完全控制。对我来说，在 aspx/ascx 文件中包含所需的 HTML 是最不可扩展和肮脏的方法。如果您想通过 CSS 设置控件的样式，则始终可以通过 CssClass 属性在服务器端设置类。如果你想通过JS访问它们，你可以在服务器端再次发出具有正确ID的JS。这样做的唯一缺点是开发人员和设计人员必须密切合作。对于任何大型项目来说，这是不可避免的。但 ASP.NET 提供的优势远远超过这些困难。不过，如果您想要符合标准的 HTML、皮肤支持和其他好东西来控制呈现的标记，您始终可以使用第三方控件。
正如 Dave Ward 已经提到的，“这是 ASP.NET 防止 ID 冲突的方法。”
一个很好的例子是，如果您尝试将控件放入自定义控件中，然后在转发器中使用该自定义控件，则自定义控件的 HTML 将为页面多次输出。
正如其他人提到的，如果您需要访问 javascript 控件，请使用 ClientScript 属性，该属性将使您能够访问 ClientScriptManager 并以这种方式将脚本注册到页面。确保在编写脚本时使用您尝试引用的控件上的 ClientID 属性，而不是仅键入控件的 ID。
如果您想对渲染的 HTML 进行更多控制，请查看 ASP.NET MVC 反而。
