Controls versus standard HTML
我正在使用ASP.NET(C＃-我知道这对这个特定的问题无关紧要，但要全面披露等等)，尽管我喜欢
还有其他问题-我注意到当您自动填充DataGrid时，它会向结果表添加我不一定要在那里存在的属性。 我知道当您依靠框架来接管一些乏味的工作时，您必须接受一定数量的"约定之上的配置"，但是在这些情况下的"约定"并不是很多已建立的约定，但不必要的额外功能。我知道ID为什么要添加前缀，但是我应该能够调整并关闭类似的功能，特别是因为作为Web标准的传播者，我无论如何都不会在单个页面中重复HTML ID。 因此，这里的问题是那些比我更老练的ASP.NET开发人员：在您开发和部署应用程序的经验中，您如何利用这些控件？您是否发现自己重新使用了硬编码的HTML？您是否使用混合？我不想围绕这些控件中的特质古怪设计我的HTML，但是，如果可能的话，我想尽可能地利用它们。 男孩要做什么？ 实际上，我很欣慰地看到这里的一些观点与我自己的观点一致：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一起工作。 (很久很抱歉) 亲身， 我认为标准的ASP.NET控件适合内部使用-在这种情况下，快速而肮脏的做法就很好。但是，我曾经和一位同时还是设计师的Web开发人员一起工作，他拒绝使用ASP.NET控件，只使用HTML代码，并在需要时添加runat =" server"标签。这更多是因为他想确切地知道他的HTML将如何呈现，而且无论如何，在某些时候，某些ASP.NET控件不会呈现为符合标准。 我坐在中间的某个地方-在适当的地方使用HTML，而不是不使用时使用HTML。您可以使用CSS控件适配器来兼顾两者 简短的答案是，除非有充分的理由，否则永远不要使用标准HTML控件的asp：...版本。 由于大多数ASP.NET书籍都涵盖了初级控件，因此初级开发人员通常会迷上使用这些控件的方法，因此假定它们必须更好。他们不是。在这一点上，经过每天8年的ASP.NET开发，我只能想到2或3种情况下使用asp实际上是有意义的：...对标准HTML进行输入控制。
@布莱恩， 我强烈建议您检查一下，对我没有帮助:) 至于服务器控件上的ID：您可以通过访问ClientID来找到将要写入浏览器的实际ID。这样，您可以结合服务器端og客户端脚本，而不必硬编码_id =" ct100_nav" _ 我总是尝试使用包含的控件而不是" hacking" HTML，因为如果以后有更新或某些改进，只需替换框架，我的所有代码仍然可以工作，而无需更改任何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 我也正在冒险进入ASP.NET，并且也遇到了类似的挫折。.但是，您很快就习惯了。您只需要记住，没有繁琐的HTML编写的原因是因为ASP.NET控件可以为您完成所有这些工作。 在某种程度上，您可以控制/调整这些内容，即使这意味着继承控件并从那里调整HTML输出。 在过去，我不得不这样做，因为某些控件默认情况下不会通过在此处和此处放置一些额外的标记来默认通过W3C验证，因此我只是简单地覆盖并根据需要进行了编辑(实际上是几分钟的修复)。 我会说了解控制系统的工作原理。然后自己敲几个门，这确实帮助我了解了引擎盖下发生的事情，因此，如果遇到任何问题，我有一个解决之道。 如果要对呈现的HTML进行太多控制，请查看ASP.NET MVC。 正如Dave Ward已经提到的那样，"这是ASP.NET防止ID冲突的方式。" 一个很好的例子是，如果您尝试将控件放入自定义控件中，然后在转发器中使用该自定义控件，以便该自定义控件的HTML将为页面多次输出。 正如其他人提到的那样，如果您需要访问javascript的控件，请使用ClientScript属性，该属性将使您可以访问ClientScriptManager并以这种方式将脚本注册到页面。在编写脚本时，请确保在尝试引用的控件上使用ClientID属性，而不仅仅是键入控件的ID。
我认为这里的大多数答案都是从设计师的角度出发的。在中小型项目中，同步代码和CSS / HTML并使它们符合标准且干净整洁似乎是一项开销。设计人员的方法是完全控制呈现的HTML。但是有很多方法可以在ASP.NET中进行完全控制。对我来说，在aspx / ascx文件中具有所需的HTML是最不可扩展且最脏的方法。如果要通过CSS为控件设置样式，则始终可以通过CssClass属性在服务器端设置类。如果要通过JS访问它们，则可以再次在服务器端发出具有正确ID的JS。这样做的唯一缺点是开发人员和设计师必须紧密合作。在任何大型项目中，这都是不可避免的。但是ASP.NET提供的优势远远超过了这些困难。 如果ASP.NET添加的ID前缀是您以后使用JS或其他方式访问它们的问题，那么您将拥有.ClientID属性服务器端。 如果由ASP.NET增加开销，则应考虑对已发出的html进行完全控制的ASP.NET MVC(仍为预览)。 我要转到MVC，因为我也不喜欢添加的所有内容。 |
