控件与标准HTML

就个人而言,

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

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

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

我只是想反驳一下这里提出的几个优点(穿上火焰服!):

Dave Ward提到了ID冲突——这是真的,但我处理得太糟糕了。我宁愿看到xpath或深度css选择器引用的节点,也不愿让ID实际上毫无用处,除非推迟到ASP。NET内部,如clientID,它只是毫无意义地使编写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开发中,我只能想到两三种情况下使用asp是有意义的:。..对标准HTML的输入控制。

至于服务器控件上的ID:您可以通过访问ClientID找到将要写入浏览器的实际ID。这样,您就可以将服务器端的日志客户端脚本结合起来,而不必硬编码_id=“ct100_nav”_

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

希望这有帮助

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

我愿意 强烈地 建议查看它们,对我帮助无穷:)

我也在探索ASP。NET,也有类似的挫折。。然而,你很快就会习惯的。你只需要记住, 你之所以没有繁琐的HTML制作,是因为ASP。NET控件为您完成所有操作 .

在某种程度上,你可以控制/调整这些东西,即使这意味着继承控制权并从那里调整HTML输出。

在过去,我不得不这样做,默认情况下,某些控件无法通过W3C验证,因为在这里和那里添加了一些额外的标记,所以我只是根据需要重写和编辑(这一修复实际上只需要几分钟)。。

我想说了解一下控制系统是如何工作的。。然后自己敲几个,这真的帮助我了解了引擎盖下发生了什么,所以如果我遇到任何问题,我知道该去哪里。

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

如果ID的前缀是由ASP。NET是你以后使用JS或其他东西访问它们的问题。..你有。ClientID属性服务器端。

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

我正在转向MVC,因为我不喜欢所有添加的东西。...

我认为这里的大多数答案都是从设计师的角度出发的。在中小型项目中,同步代码和CSS/HTML并使其符合标准和干净似乎是一项开销。设计师的方法是完全控制渲染的HTML。但是在ASP中有很多方法可以完全控制。网。对我来说,在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 相反。