C# 控件与标准 HTML

Controls versus standard HTML

提问by Brian Warshaw

I'm getting into ASP.NET (C# - I know it doesn't matter for this particular question, but full disclosure and all that), and while I love that the asp:-style controls save me a lot of tedious HTML-crafting, I am often frustrated with certain behaviors. I encountered one last night when working with Master Pages: my <asp:BulletedList ID="nav">, when converted into HTML, became <ul id="ct100_nav">.

我正在使用 ASP.NET（C# - 我知道这对这个特定问题无关紧要，但是完全公开等等），虽然我喜欢asp:-style 控件为我节省了很多乏味的 HTML 制作，我经常对某些行为感到沮丧。我遇到过一个昨晚母版页工作时：我<asp:BulletedList ID="nav">，当转换成HTML，成了<ul id="ct100_nav">。

There are other issues--I noticed that when you auto-populate a DataGrid, it adds attributes to the resulting table that I don't necessarily want there.

还有其他问题——我注意到当您自动填充 DataGrid 时，它会向结果表添加我不一定想要的属性。

I know that there is a certain amount of "convention over configuration" that you have to accept when you rely on a framework to take over some of your tedious duties, but the "conventions" in these cases aren't so much any established conventions, but rather unnecessary extras. I know whythe ID adds the prefix, but I should be able to tweak and turn things like this off, especially since, as a bit of a web standards evangelist, I don't duplicated HTML id's in a single page anyway.

我知道当你依靠一个框架来接管你的一些繁琐的职责时，你必须接受一定数量的“约定优于配置”，但在这些情况下，“约定”并不是任何既定约定，而是不必要的附加功能。我知道为什么ID 添加前缀，但我应该能够调整和关闭这样的东西，特别是因为，作为一个网络标准的传播者，我无论如何都不会在单个页面中复制 HTML id。

So the question here is for those ASP.NET devs more seasoned than I: in your experiences in developing and deploying apps, how do you leverage these controls? Do you find yourself resorting back to hard-coded HTML? Do you use a blend? I don't want to design my HTML around idiosyncratic quirks in these controls, but, if possible, I'd like to leverage them when possible.

所以这里的问题是针对那些比我经验丰富的 ASP.NET 开发人员：根据您开发和部署应用程序的经验，您如何利用这些控件？您是否发现自己重新使用硬编码的 HTML？你用混合物吗？我不想围绕这些控件中的特殊怪癖来设计我的 HTML，但是，如果可能的话，我想尽可能利用它们。

What's a boy to do?

一个男孩要做什么？

采纳答案by JamesSugrue

Personally,

亲身，

I think the standard ASP.NET controls are fine for inhouse stuff - quick and dirty is good in that scenario. But, I once worked with a web developer who was also a designer and he refused to use the ASP.NET controls and only code in HTML and add runat="server" tags when needed. This was more because he wanted to know exactly how his HTML was going to be rendered, and at the time anyway, some of the ASP.NET controls wouldn't render to standards compliance.

我认为标准的 ASP.NET 控件适用于内部的东西 - 在这种情况下快速和肮脏是好的。但是，我曾经与一位也是设计师的 Web 开发人员一起工作，他拒绝使用 ASP.NET 控件，只使用 HTML 编写代码，并在需要时添加 runat="server" 标签。这更多是因为他想确切地知道他的 HTML 将如何呈现，而且当时无论如何，一些 ASP.NET 控件不会呈现符合标准。

I sit somewhere in the middle - use HTML where appropriate and not when not. You can sort of best of both worlds with the CSS control Adapters

我坐在中间的某个地方 - 在适当的时候使用 HTML，而不是在不合适的时候。您可以使用CSS 控件适配器实现两全其美

回答by Rob Cooper

I too am on my adventure into ASP.NET and have also had similar frustrations.. However, you soon get used to it. You just need to remember, the reason you dont have the tedious HTML crafting is because the ASP.NET controls do it all for you.

我也在探索 ASP.NET，也遇到过类似的挫折。但是，您很快就会习惯它。你只需要记住，你没有繁琐的 HTML 制作的原因是因为 ASP.NET 控件为你做这一切。

To some extent you can control/tweak these things, even if it means inheriting the control and tweaking the HTML output from there.

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

I have had to do that in the past, where certain controls were not passing W3C validation by default by putting some extra markup here and there, so I simply overrode and edited as necessary (a fix that too literally a couple of minutes)..

过去我不得不这样做，其中某些控件默认情况下没有通过 W3C 验证，通过在此处和那里放置一些额外的标记，所以我只是根据需要进行了覆盖和编辑（从字面上看是几分钟的修复）。

I would say learn about how the controls system works.. Then knock a few together yourself, this has really helped me grok whats going on under the hood, so if I ever get any problems, I have an idea where to go.

我会说了解控制系统的工作原理..然后自己敲几个，这真的帮助我理解引擎盖下发生的事情，所以如果我遇到任何问题，我知道去哪里。

回答by Espo

As for the ID's on server-controls: You can find the actually ID that is going to be written to the browser by accessing ClientID. That way you can combine server-side og client-side scripting and still dont have to hardcode _id="ct100_nav"_

至于服务器控件上的 ID：您可以通过访问 ClientID 找到将要写入浏览器的实际 ID。这样你就可以结合服务器端 og 客户端脚本，而仍然不必硬编码 _id="ct100_nav"_

I always try to use the included controls instead of "hacking" HTML, because if there is an update or some improvement later on, all my code will still work by just replacing the framework and I don't have to change any HTML.

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

Hope this helps

希望这可以帮助

回答by Davide Vosti

If the ID's prefix added by ASP.NET is an issue for you to access them later using JS or something... you have the .ClientID property server side.

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

If the overhead added by ASP.NET you should consider ASP.NET MVC (still preview) where you have full control over the emitted html.

如果 ASP.NET 增加了开销，您应该考虑使用 ASP.NET MVC（仍然预览），您可以在其中完全控制发出的 html。

I'm moving to MVC because I don't like all that stuffs added too....

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

回答by Rob Cooper

@Brian, Yup! You can pretty much control all the behaviour.. Consider looking into creating Custom Controls (there are three types). I recently gave an overview of them in my question here.

@布莱恩，是的！您几乎可以控制所有行为.. 考虑研究创建自定义控件（共有三种类型）。最近，我给他们的概述在我的问题在这里。

I would stronglyrecommend checking them out, has help me no end :)

我强烈建议检查它们，对我的帮助无穷无尽:)

回答by Slavo

I think most of the answers here take a designer's point of view. On a small-to-medium project it might seem like an overhead to synchronize code and CSS/HTML and make them standards-compliant and clean. A designer's way to do that is to have full control over rendered HTML. But there's many ways to have that full control in ASP.NET. And for me, having the required HTML in the aspx/ascx file is the most non-scalable and dirty way to do it. If you want to style controls through CSS, you can always set a class server-side through the CssClass property. If you want to access them through JS, you can emit the JS with right IDs server-side again. The only disadvantage that this provides is that a dev and a designer have to work together closely. On any large project this is unavoidable anyway. But the advantages ASP.NET provides far outnumber these difficulties. Still, if you want standards-compliant HTML, skinning support and other goodies to control rendered markup, you can always use thrid-party controls.

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

回答by Dave Ward

The HTML renders with those sort of IDs because its ASP.NET's way of preventing ID collisions. Each container control, such as a Master page or Wizard control, will prepend an "ID_" on its childrens' IDs.

HTML 使用这些类型的 ID 呈现，因为它的 ASP.NET 防止 ID 冲突的方式。每个容器控件，例如母版页或向导控件，都将在其子控件的 ID 上添加“ID_”。

In the case of your bullet list, the ListView provides a nice middle ground. You can still bind it to a datasource, but it gives you much tighter control over the rendered HTML. Scott Gu has a nice intro to the ListView here:

对于您的项目符号列表，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

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

回答by Rex Morgan

As Dave Ward has already mentioned, "it's ASP.NET's way of preventing ID collisions."

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

A very good example of this is if you're attempting to put a control inside of a custom control, then use that custom control in a repeater, so that custom control's HTML would be output multiple times for the page.

一个很好的例子是，如果您尝试将控件放在自定义控件中，然后在转发器中使用该自定义控件，那么自定义控件的 HTML 将针对页面多次输出。

As others have mentioned, if you need to access the controls for javascript, use the ClientScript property which will give you access to a ClientScriptManager and register your scripts to the page this way. Be sure when writing your scripts to use the ClientID property on the control you're trying to reference instead of just typing in the control's ID.

正如其他人所提到的，如果您需要访问 javascript 控件，请使用 ClientScript 属性，该属性将使您能够访问 ClientScriptManager 并以这种方式将您的脚本注册到页面。确保在编写脚本以在您尝试引用的控件上使用 ClientID 属性时，而不是仅仅输入控件的 ID。

回答by Jason Kester

The short answer is that you should never use an asp:... version of a standard HTML control unless you have a really good reason.

简短的回答是，除非您有充分的理由，否则永远不要使用标准 HTML 控件的 asp:... 版本。

Junior developers often get suckered into using those controls because they're covered in most ASP.NET books, so it's assumed that they must be better. They're not. At this point, after 8 years of daily ASP.NET development, I can only think of 2 or 3 cases where it actually makes sense to use an asp:... INPUT control over a standard HTML one.

初级开发人员经常被吸引到使用这些控件，因为大多数 ASP.NET 书籍都介绍了它们，因此假定它们必须更好。他们不是。在这一点上，经过 8 年的日常 ASP.NET 开发，我只能想到 2 或 3 种情况，其中使用 asp:... INPUT 控制标准 HTML 是有意义的。

回答by annakata

I'm actually quite relieved to see some opinions here agreeing with my own: ASP.NET as a template language is very poor.

看到这里的一些观点与我自己的观点一致，我真的很欣慰：ASP.NET 作为模板语言非常糟糕。

I'd just like to rebut a couple of the pro points made here (flamesuit on!):

我只想反驳这里提出的一些专业观点（穿上flamesuit！）：

Dave Ward mentions ID collisions - this is true, but my how badly handled. I would have preferred to see nodes referenced by xpath or deep css selectors than by making the ID effectively useless except by deferring to ASP.NET internals like clientID - it just makes writing CSS and JS that much harder pointlessly.

Dave Ward 提到了 ID 冲突——这是真的，但我处理得多么糟糕。我宁愿看到 xpath 或深层 css 选择器引用的节点，也不愿让 ID 有效地无用，除非推迟到像 clientID 这样的 ASP.NET 内部 - 这只会使编写 CSS 和 JS 变得毫无意义。

Rob Cooper talks about how the controls are a replacement for HTML so it's all fine (paraphrasing, forgive me Rob) - well it's not fine, because they took an existing and well understood language and said "no, you have to do things our way now", and their way is verypoorly implemented. e.g. asp:panel renders a table in one browser and a div in another! Without documentation or execution, the markup for a login control (and many others) isn't predictable. How are you going to get a designer to write CSS against that?

Rob Cooper 谈到控件如何替代 HTML，所以一切都很好（释义，原谅我 Rob） - 好吧，这不好，因为他们采用了现有且易于理解的语言并说“不，你必须按照我们的方式做事现在”，而且他们的方式实施得很差。例如 asp:panel 在一个浏览器中呈现一个表格，在另一个浏览器中呈现一个 div！如果没有文档或执行，登录控件（以及许多其他控件）的标记是不可预测的。您将如何让设计师针对此编写 CSS？

Espo writes about how controls give you the benefits of abstraction if the platform changes the html - well this is clearly circular (It's only changing because the platform is changing, and wouldn't need to if I just had my own HTML there instead) and actually creates a problem. If the control is going to change with updates again how is my CSS supposed to cope with that?

Espo 写道，如果平台更改了 html，控件如何为您提供抽象的好处——这显然是循环的（它只是因为平台在变化而变化，如果我只是在那里拥有自己的 HTML，则不需要）和实际上会产生问题。如果控件将再次随着更新而改变，我的 CSS 应该如何应对？

Apologists will say "yes but you can change this in the config" or talk about overriding controls and custom controls. Well why should I have to? The css friendly controls package meant to fix some of these problems is anything but with it's unsemantic markup and it doesn't address the ID issue.

辩护者会说“是的，但您可以在配置中更改它”或谈论覆盖控件和自定义控件。为什么我必须这样做？旨在解决其中一些问题的 css 友好控件包是任何东西，但它是无语义的标记，它没有解决 ID 问题。

It's impossible to implement MVC (the abstract concept, not the 3.5 implementation) out of the box with webform apps becuase these controls so tightly bind the view and control. There's a barrier of entry for the traditional web designer now because he has to get involved with server side code to implement what used to be the separate domains of CSS and JS. I sympathise with these people.

使用 webform 应用程序开箱即用地实现 MVC（抽象概念，而不是 3.5 实现）是不可能的，因为这些控件将视图和控件绑定得如此紧密。现在对于传统的网页设计师来说有一个进入障碍，因为他必须参与服务器端代码来实现以前是独立的 CSS 和 JS 域。我同情这些人。

I do strongly agree with Kiwi's point that controls allow for some very rapid development for apps of a certain profile, and I accept that for whatever reason some programmers find HTML unpleasant, and further that the advantages the other parts of ASP.NET give you, which requires these controls, maybe worth the price.

我非常同意 Kiwi 的观点，即控件允许对特定配置文件的应用程序进行一些非常快速的开发，并且我接受无论出于何种原因，一些程序员觉得 HTML 不愉快，而且 ASP.NET 的其他部分给您带来的优势，这需要这些控制，可能是值得的。

However, Iresent the loss of control, I feel the model of dealing with things like classes, styles and scripting on the codebehind is a wrongheaded step backwards, and I further feel that there are better models for templating (implementation of microformats and xslt for this platform) although replacing controls with these is non-trivial.

然而，我对失去控制感到不满，我觉得在代码隐藏上处理类、样式和脚本等事情的模型是一个错误的倒退，我进一步觉得有更好的模板模型（微格式和 xslt 的实现）这个平台），尽管用这些替换控件并非易事。

I think ASP.NET could learn a lot from related tech in LAMP and rails world, until then I hope to work with 3.5 MVC where I can.

我认为 ASP.NET 可以从 LAMP 和 Rails 世界的相关技术中学到很多东西，在那之前我希望尽可能使用 3.5 MVC。

(sorry that was so long </rant>)

（对不起，太长了</rant>）