控件与标准HTML

就个人而言,

我认为标准的ASP.NET控件适合内部使用——在这种情况下,快速和脏的控件是很好的。但是,我曾经和一个同时也是设计师的Web开发人员合作过,他拒绝使用ASP.NET控件,只使用HTML代码,并在需要时添加runat=“server”标记。这更多是因为他想知道他的HTML将如何呈现,而且在当时,一些ASP.NET控件不会呈现为符合标准。

我坐在中间的某个地方-在适当的地方使用HTML,而不是在不合适的时候。你可以用 CSS control Adapters

实际上,我很欣慰地看到这里的一些观点与我自己的观点一致:作为模板语言的ASP.NET非常差。

我只是想反驳一下这里的一些专业观点(穿上防火服!):

DaveWard提到了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可以从LightandRails世界的相关技术中学到很多东西,直到那时我希望能尽可能地与3.5 MVC合作。

(很抱歉,这么久了,</rant>)

简而言之,您不应该使用ASP:…标准HTML控件的版本,除非您有充分的理由。

初级开发人员经常被这些控件所吸引,因为它们被大多数ASP.NET书籍所覆盖,所以假设它们必须更好。它们不是。现在,在每天开发ASP.NET 8年之后,我只能想到2到3个实际使用ASP有意义的案例:…对标准HTML控件的输入控件。

至于服务器控件上的ID:您可以通过访问clientID找到将要写入浏览器的实际ID。这样,您就可以将服务器端OG客户端脚本结合起来,而不必对其进行硬编码。_

我总是尝试使用包含的控件而不是“黑客”HTML,因为如果以后有更新或一些改进,我的所有代码仍然可以通过替换框架来工作,而且我不必更改任何HTML。

希望这有帮助

@布瑞恩, 是的!你几乎可以控制所有的行为。考虑创建自定义控件(有三种类型)。我最近在我的问题中概述了它们 here .

我愿意 强烈地 建议把它们检查出来,有助于我无穷无尽:)

我也在进入ASP.NET的冒险中,也经历过类似的挫折。不过,你很快就会习惯的。你只需要记住, 你没有这种冗长的HTML制作方法的原因是因为ASP.NET控件为你做了所有这些。 .

在某种程度上,您可以控制/调整这些内容,即使这意味着继承控件并从中调整HTML输出。

在过去,我必须这样做,在默认情况下,某些控件没有通过W3C验证,只是在这里和那里添加了一些额外的标记,所以我只是在必要时进行了覆盖和编辑(这是一个修复,字面上说太长了几分钟)。

我想说,了解控制系统的工作原理……然后你自己敲几下,这真的帮助我摸索引擎盖下发生了什么,所以如果我有任何问题,我有一个主意去哪里。

HTML使用这些类型的ID呈现,因为它的ASP.NET防止ID冲突的方式。每个容器控件(如母版页或向导控件)都将在其子代的ID上预先设置一个“ID”。

对于项目符号列表,ListView提供了一个很好的中间位置。您仍然可以将其绑定到数据源,但它使您对呈现的HTML具有更严格的控制。顾司各特在这里有一个很好的列表视图介绍:

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

如果ASP.NET添加的ID前缀对您以后使用JS或其他方式访问它们是一个问题…您有.clientid属性服务器端。

如果ASP.NET增加了开销,您应该考虑ASP.NET MVC(仍然预览),在这里您可以完全控制发出的HTML。

我要搬到MVC,因为我不喜欢所有的东西都加进去…

我认为这里的大多数答案都是设计师的观点。在中小型项目中,同步代码和CSS/HTML并使它们符合标准和干净似乎是一种开销。设计师的方法是完全控制呈现的HTML。但是在ASP.NET中有很多方法可以完全控制它。对我来说,在aspx/ascx文件中使用所需的HTML是最不可扩展和最脏的方法。如果要通过css设置控件的样式,则可以始终通过css class属性设置类服务器端。如果您想通过JS访问它们,可以再次发出具有正确IDS服务器端的JS。这提供的唯一缺点是开发人员和设计人员必须紧密合作。在任何大型项目中,这都是不可避免的。但是ASP.NET的优势远远超过了这些困难。 但是,如果您希望标准兼容的HTML、剥皮支持和其他好处来控制呈现的标记,则可以始终使用第三方控件。

正如DaveWard已经提到的,“这是ASP.NET防止ID冲突的方法。”

一个很好的例子是,如果你试图把一个控件放在一个自定义控件中,然后在中继器中使用这个自定义控件,这样自定义控件的HTML将为页面输出多次。

正如其他人提到的,如果您需要访问javascript的控件,请使用clientscript属性,该属性将授予您访问clientscriptmanager的权限,并以这种方式将脚本注册到页面。在编写脚本以使用您试图引用的控件的clientID属性时,请确保不要只键入控件的ID。

如果您希望对呈现的HTML进行如此多的控制,请查看 ASP.NET MVC 相反。