My<cod/>.net
Управление по сравнению со стандартным HTML
Я вхожу в ASP.NET (C# - я знаю, что это не имеет значения для этого конкретного вопроса, но полное раскрытие и все такое), и хотя мне нравится, что элементы управления в стиле asp: избавляют меня от многих утомительных HTML-крафтов, я часто разочаровываюсь в определенных поведениях. Вчера вечером я столкнулся с одним из них при работе с главными страницами: мой <asp:BulletedList ID="nav"> , преобразованный в HTML, стал <ul id="ct100_nav"> .
Есть и другие проблемы-я заметил, что когда вы автоматически заполняете a DataGrid, он добавляет атрибуты к результирующей таблице, которые мне не обязательно там нужны.
Я знаю, что есть определенное количество "convention over configuration", которое вы должны принять, когда вы полагаетесь на рамки, чтобы взять на себя некоторые из ваших утомительных обязанностей, но "conventions" в этих случаях не столько какие-то установленные условности, а скорее ненужные дополнения. Я знаю, почему ID добавляет префикс, но я должен быть в состоянии настроить и отключить подобные вещи, тем более что, будучи немного евангелистом веб-стандартов, я все равно не дублирую HTML id на одной странице.
Поэтому вопрос здесь для тех разработчиков ASP.NET, которые более опытны, чем я: в вашем опыте разработки и развертывания приложений, как вы используете эти элементы управления? Может быть, вы снова прибегаете к жесткому коду HTML? Вы пользуетесь смесью? Я не хочу создавать свой HTML вокруг идиосинкразических причуд в этих элементах управления, но, если это возможно, я хотел бы использовать их, когда это возможно.
А что делать мальчику?
Сам,
Я думаю, что стандартные элементы управления ASP.NET хороши для внутренних вещей - быстрые и грязные хороши в этом сценарии. Но однажды я работал с веб-разработчиком, который также был дизайнером, и он отказался использовать элементы управления ASP.NET и только код в HTML и добавлять теги runat="server", когда это необходимо. Это было больше потому, что он хотел точно знать, как будет выглядеть его HTML, и в то же время некоторые из элементов управления ASP.NET не будут соответствовать стандартам.
Я сижу где - то посередине-использую HTML там, где это уместно, а не когда нет. Вы можете выбрать лучшее из обоих миров с помощью адаптеров управления CSS
На самом деле я очень рад видеть здесь некоторые мнения, согласующиеся с моими собственными: ASP.NET как шаблонный язык очень беден.
Я просто хотел бы опровергнуть пару профессиональных моментов, сделанных здесь (flamesuit on!):
Дэйв Уорд упоминает ID столкновений-это правда,но мой как плохо обработан. Я бы предпочел видеть узлы, на которые ссылаются селекторы xpath или deep css, чем делать ID фактически бесполезным, за исключением того, что он отсылает к ASP.NET внутренним элементам, таким как clientID - это просто делает написание CSS и JS намного сложнее бессмысленно.
Роб Купер говорит о том, что элементы управления являются заменой для HTML, так что все в порядке (перефразируя, простите меня, Роб) - ну, это не нормально, потому что они взяли существующий и хорошо понятный язык и сказали: "Нет, теперь вы должны делать все по-нашему", и их способ очень плохо реализован. например, asp:panel отображает таблицу в одном браузере и div в другом! Без документации или выполнения markup для элемента управления login (и многих других) не является предсказуемым. Как вы собираетесь заставить дизайнера написать CSS против этого?
Espo пишет о том, как элементы управления дают вам преимущества абстракции, если платформа изменяет html - ну, это явно циклический процесс (он меняется только потому, что меняется платформа, и мне не нужно было бы этого делать, если бы вместо этого у меня был свой HTML) и фактически создает проблему. Если элемент управления снова изменится с обновлениями, как мой CSS должен справиться с этим?
Апологеты будут говорить "yes but you can change this in the config" или говорить о переопределении элементов управления и пользовательских элементах управления. Ну и зачем мне это делать? Пакет css friendly controls, предназначенный для устранения некоторых из этих проблем, является чем угодно, но с его несемантичным markup, и он не решает проблему ID.
Невозможно реализовать MVC (абстрактная концепция, а не реализация 3.5) из коробки с приложениями webform, потому что эти элементы управления так плотно связывают представление и контроль. Теперь для традиционного веб-дизайнера существует барьер входа, потому что он должен быть вовлечен в код на стороне сервера, чтобы реализовать то, что раньше было отдельными доменами CSS и JS. Я сочувствую этим людям.
Я полностью согласен с точкой зрения Киви, что элементы управления позволяют очень быстро разрабатывать приложения определенного профиля, и я согласен с тем, что по какой-то причине некоторые программисты находят HTML неприятным, а также с тем, что преимущества, которые дают вам другие части ASP.NET, которые требуют этих элементов управления, могут стоить того.
Тем не менее, я возмущен потерей контроля, я чувствую, что модель работы с такими вещами, как классы, стили и сценарии на codebehind-это ошибочный шаг назад, и я также чувствую, что есть лучшие модели для шаблонизации (реализация microformats и xslt для этой платформы), хотя замена элементов управления ими нетривиальна.
Я думаю, что ASP.NET может многому научиться у родственных технологий в мире LAMP и rails, а до тех пор я надеюсь работать с 3.5 MVC, где смогу.
(извините, что так долго </rant>)
Короткий ответ заключается в том, что вы никогда не должны использовать asp:... версия стандартного элемента управления HTML, если у вас нет действительно веской причины.
Младшие разработчики часто поддаются соблазну использовать эти элементы управления, потому что они описаны в большинстве книг ASP.NET, поэтому предполагается, что они должны быть лучше. Но это не так. На данный момент, после 8 лет ежедневного развития ASP.NET, я могу думать только о 2 или 3 случаях, когда действительно имеет смысл использовать asp:... INPUT контроль над стандартным HTML.
Что касается ID на серверных элементах управления: вы можете найти собственно ID, который будет записан в браузер, обратившись к ClientID. Таким образом, вы можете объединить серверные OG клиентские сценарии и все еще не должны жестко кодировать _id= " ct100_nav"_
Я всегда стараюсь использовать включенные элементы управления вместо "hacking" HTML, потому что если позже произойдет обновление или какое-то улучшение, весь мой код все равно будет работать, просто заменив фреймворк, и мне не нужно будет менять никакой HTML.
Надеюсь, это поможет
@Brian, Ага! Вы можете в значительной степени контролировать все поведение.. Рассмотрите возможность создания пользовательских элементов управления (существует три типа). Я недавно дал обзор их в своем вопросе здесь .
Я бы настоятельно рекомендовал проверить их, имеет помощь мне нет конца :)
Я тоже нахожусь в своем приключении в ASP.NET и также имел подобные разочарования.. Впрочем, вы скоро к этому привыкнете. Вам просто нужно помнить, что причина, по которой у вас нет утомительного крафта HTML, заключается в том, что элементы управления ASP.NET делают все это за вас .
В какой-то степени вы можете контролировать/настраивать эти вещи, даже если это означает наследование элемента управления и настройку вывода HTML оттуда.
Мне приходилось делать это в прошлом, когда некоторые элементы управления не проходили проверку W3C по умолчанию, добавляя некоторые дополнительные markup здесь и там, поэтому я просто перешел и отредактировал по мере необходимости (исправление, которое тоже буквально через пару минут)..
Я бы сказал, узнать о том, как работает система управления.. Тогда соберите несколько вместе сами, это действительно помогло мне понять, что происходит под капотом, так что если у меня когда-нибудь возникнут проблемы, у меня есть идея, куда идти.
HTML отрисовывается с таким видом IDs, потому что его ASP.NET's способ предотвращения ID столкновений. Каждый элемент управления контейнера, такой как главная страница или элемент управления мастера, будет предварять "ID_" на своем дочернем элементе IDs.
В случае вашего маркированного списка ListView обеспечивает хорошую середину. Вы все еще можете привязать его к источнику данных, но это дает вам гораздо более жесткий контроль над визуализируемым HTML. У Скотта ГУ есть хорошее вступление к ListView здесь:
Если вы хотите получить такой большой контроль над рендерингом HTML, вместо этого загляните в ASP.NET MVC .
Если префикс ID, добавленный ASP.NET, является проблемой для вас, чтобы получить доступ к ним позже, используя JS или что-то еще... у вас есть свойство .ClientID на стороне сервера.
Если накладные расходы добавлены ASP.NET, вы должны рассмотреть ASP.NET MVC (все еще предварительный просмотр), где у вас есть полный контроль над испускаемым html.
Я переезжаю в MVC, потому что мне тоже не нравятся все эти материалы....
Я думаю, что большинство ответов здесь принимают точку зрения дизайнера. В проекте small-to-medium это может показаться накладными расходами для синхронизации кода и CSS/HTML и обеспечения их соответствия стандартам и чистоты. Способ дизайнера сделать это-иметь полный контроль над рендерингом HTML. Но есть много способов получить этот полный контроль в ASP.NET. И для меня наличие необходимого HTML в файле aspx/ascx - это самый немасштабируемый и грязный способ сделать это. Если вы хотите стилизовать элементы управления через CSS, вы всегда можете установить класс на стороне сервера через свойство CssClass. Если вы хотите получить доступ к ним через JS, вы можете снова создать JS с правой IDs серверной стороной. Единственный недостаток, который это дает, заключается в том, что разработчик и дизайнер должны тесно сотрудничать. В любом крупном проекте это неизбежно в любом случае. Но преимущества, которые предоставляет ASP.NET, намного превосходят эти трудности. Тем не менее, если вы хотите, чтобы стандарты соответствовали HTML, поддержка скининга и другие плюсы для управления визуализацией markup, вы всегда можете использовать элементы управления thrid-party.
Как уже упоминал Дэйв Уорд, " это ASP.NET's способ предотвращения ID столкновений."
Очень хороший пример этого - если вы пытаетесь поместить элемент управления в пользовательский элемент управления, а затем использовать этот пользовательский элемент управления в повторителе, чтобы пользовательский элемент управления HTML выводился несколько раз для страницы.
Как уже упоминалось, если вам нужно получить доступ к элементам управления для javascript, используйте свойство ClientScript, которое даст вам доступ к ClientScriptManager и зарегистрирует ваши сценарии на странице таким образом. При написании скриптов обязательно используйте свойство ClientID для элемента управления, на который вы пытаетесь ссылаться, а не просто вводите его ID.