Элементы управления по сравнению со стандартным HTML

Лично,

Я думаю, что стандартные элементы управления ASP.NET подходят для внутренних работ - быстрые и грязные в этом случае хороши. Но однажды я работал с веб-разработчиком, который также был дизайнером, и он отказался использовать элементы управления ASP.NET и код только в HTML и добавлять теги runat = "server" при необходимости. Это было больше потому, что он хотел точно знать, как его HTML-код будет отображаться, и в любом случае в то время некоторые элементы управления ASP.NET не отображались в соответствии со стандартами.

Я сижу где-то посередине - используйте HTML там, где это необходимо, а когда нет. Вы можете получить лучшее из обоих миров с помощью адаптеров управления CSS

На самом деле я очень рад видеть здесь некоторые мнения, совпадающие с моими: ASP.NET как язык шаблонов очень плох.

Я просто хотел бы опровергнуть пару замечаний, сделанных здесь профессионалом (надевать костюм с пламенем!):

Дэйв Уорд упоминает о конфликтах идентификаторов - это правда, но как плохо с ними справились. Я бы предпочел видеть узлы, на которые ссылаются селекторы xpath или deep css, чем делая ID фактически бесполезным, кроме как путем откладывания на внутренние компоненты ASP.NET, такие как clientID - это просто делает написание CSS и JS бессмысленно намного сложнее.

Роб Купер говорит о том, что элементы управления заменяют HTML, так что все в порядке (перефразируя, простите меня, Роб) - ну, это не нормально, потому что они взяли существующий и хорошо понимаемый язык и сказали: «Нет, вы должны делать все по-нашему. now ", и их способ очень плохо реализован. например asp: panel отображает таблицу в одном браузере и div в другом! Без документации или выполнения разметка для элемента управления входом (и многих других) непредсказуема. Как вы собираетесь заставить дизайнера писать CSS против этого?

Эспо пишет о том, как элементы управления дают вам преимущества абстракции, если платформа изменяет html - ну, это явно круговой (он меняется только потому, что меняется платформа, и не было бы необходимости, если бы у меня был собственный HTML вместо этого) и на самом деле создает проблему. Если элемент управления снова изменится с обновлениями, как мой CSS должен с этим справиться?

Апологеты скажут «да, но вы можете изменить это в конфигурации» или поговорите о переопределении элементов управления и пользовательских элементов управления. Зачем мне это нужно? Пакет дружественных css элементов управления, предназначенный для исправления некоторых из этих проблем, не имеет смысла и не решает проблему с идентификатором.

Невозможно реализовать MVC (абстрактную концепцию, а не реализацию 3.5) из коробки с приложениями веб-форм, потому что эти элементы управления так тесно связывают представление и элемент управления. Теперь для традиционного веб-дизайнера существует барьер входа, потому что он должен заниматься серверным кодом, чтобы реализовать то, что раньше было отдельными доменами CSS и JS. Я сочувствую этим людям.

Я полностью согласен с точкой зрения Киви о том, что элементы управления позволяют очень быстро разрабатывать приложения определенного профиля, и я согласен с тем, что по какой-то причине некоторые программисты находят HTML неприятным, и, кроме того, преимущества, которые дают вам другие части ASP.NET, для которого требуются эти элементы управления, может окупиться.

Однако я возмущен потерей контроля, я считаю, что модель работы с такими вещами, как классы, стили и сценарии в программном коде, является ошибочным шагом назад, и я также чувствую, что есть лучшие модели для шаблонов (реализация микроформатов и xslt для этой платформы), хотя замена элементов управления ими нетривиальна.

Я думаю, что ASP.NET может многому научиться у связанных технологий в мире LAMP и rails, а до тех пор я надеюсь поработать с 3.5 MVC там, где смогу.

(извините, что это было так долго ‹/rant›)

Короткий ответ заключается в том, что вам никогда не следует использовать asp: ... версию стандартного элемента управления HTML, если у вас нет действительно веской причины.

Младшие разработчики часто втягиваются в использование этих элементов управления, потому что они описаны в большинстве книг по ASP.NET, поэтому предполагается, что они должны быть лучше. Они не. На данный момент, после 8 лет ежедневной разработки ASP.NET, я могу вспомнить только 2 или 3 случая, когда действительно имеет смысл использовать элемент управления asp: ... INPUT вместо стандартного элемента HTML.

Что касается идентификаторов на серверных элементах управления: вы можете найти фактический идентификатор, который будет записан в браузер, обратившись к ClientID. Таким образом, вы можете комбинировать сценарии на стороне сервера и на стороне клиента и при этом не нужно жестко кодировать _id = "ct100_nav" _

Я всегда стараюсь использовать включенные элементы управления вместо «взлома» HTML, потому что, если позже будет обновление или какое-то улучшение, весь мой код будет работать, просто заменив фреймворк, и мне не нужно будет менять какой-либо HTML.

Надеюсь это поможет

@ Брайан, Ага! Вы можете в значительной степени контролировать все поведение. Рассмотрите возможность создания пользовательских элементов управления (есть три типа). Недавно я дал их обзор в своем вопросе здесь.

Я бы настоятельно порекомендовал их проверить, это мне бесконечно :)

Я тоже нахожусь в своем приключении в ASP.NET, и у меня тоже были подобные разочарования ... Однако вы скоро к этому привыкнете. Вам просто нужно помнить, причина того, что у вас нет утомительного создания HTML, заключается в том, что элементы управления ASP.NET делают все за вас.

В некоторой степени вы можете контролировать / настраивать эти вещи, даже если это означает наследование элемента управления и настройку вывода HTML оттуда.

Мне приходилось делать это в прошлом, когда определенные элементы управления не проходили проверку W3C по умолчанию, добавляя некоторую дополнительную разметку здесь и там, поэтому я просто отменял и редактировал по мере необходимости (исправление, которое слишком буквально за пару минут).

Я бы сказал, узнайте, как работает система управления ... Затем соберите несколько вместе, это действительно помогло мне понять, что происходит под капотом, поэтому, если у меня когда-нибудь возникнут какие-либо проблемы, у меня есть идея, куда идти.

HTML визуализируется с такими идентификаторами, потому что это способ предотвращения конфликтов идентификаторов в ASP.NET. Каждый контейнерный элемент управления, такой как главная страница или элемент управления Wizard, будет добавлять «ID_» к своим дочерним идентификаторам.

В случае вашего маркированного списка ListView обеспечивает хорошую золотую середину. Вы по-прежнему можете привязать его к источнику данных, но это дает вам гораздо более жесткий контроль над визуализированным HTML. У Скотта Гу есть хорошее введение в 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, является проблемой для вас, чтобы получить к нему доступ позже, используя JS или что-то еще ... у вас есть сторона сервера свойств .ClientID.

Если накладные расходы добавлены ASP.NET, вам следует рассмотреть ASP.NET MVC (все еще предварительная версия), где у вас есть полный контроль над создаваемым HTML.

Я перехожу на MVC, потому что мне тоже не нравится все это добавленное ....

Я думаю, что большинство ответов здесь основано на точке зрения дизайнера. В малых и средних проектах может показаться, что синхронизировать код и CSS / HTML и сделать их чистыми и совместимыми со стандартами - это накладные расходы. Способ дизайнера сделать это - получить полный контроль над отображаемым HTML. Но есть много способов получить полный контроль в ASP.NET. И для меня наличие необходимого HTML в файле aspx / ascx - самый немасштабируемый и грязный способ сделать это. Если вы хотите стилизовать элементы управления с помощью CSS, вы всегда можете установить класс на стороне сервера с помощью свойства CssClass. Если вы хотите получить к ним доступ через JS, вы можете снова запустить JS с правильными идентификаторами на стороне сервера. Единственный недостаток, который это дает, заключается в том, что разработчик и дизайнер должны тесно сотрудничать. В любом случае это неизбежно в любом большом проекте. Но преимущества, которые предоставляет ASP.NET, намного превосходят эти трудности. Тем не менее, если вам нужен совместимый со стандартами HTML, поддержка скинов и другие полезности для управления отображаемой разметкой, вы всегда можете использовать сторонние элементы управления.

Как уже упоминал Дэйв Уорд, «это способ ASP.NET предотвращать конфликты идентификаторов».

Очень хороший пример этого - если вы пытаетесь поместить элемент управления внутри настраиваемого элемента управления, а затем использовать этот настраиваемый элемент управления в репитере, чтобы HTML-код настраиваемого элемента управления выводился для страницы несколько раз.

Как уже упоминалось, если вам нужно получить доступ к элементам управления для javascript, используйте свойство ClientScript, которое предоставит вам доступ к ClientScriptManager и таким образом зарегистрирует ваши скрипты на странице. При написании сценариев обязательно используйте свойство ClientID элемента управления, на который вы пытаетесь сослаться, вместо того, чтобы просто вводить идентификатор элемента управления.

Если вам нужен такой полный контроль над визуализированным HTML, лучше изучите ASP.NET MVC.