Элементы управления по сравнению со стандартным HTML
https://stackoverflow.com/questions/22084
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Я изучаю ASP.NET (C# — я знаю, что для этого конкретного вопроса это не имеет значения, но полное раскрытие информации и все такое), и хотя мне это нравится, asp:Элементы управления -style избавляют меня от утомительной работы с HTML, меня часто расстраивает определенное поведение.Вчера вечером я столкнулся с одним, работая с главными страницами:мой <asp:BulletedList ID="nav">, при преобразовании в HTML, стал <ul id="ct100_nav">.
Есть и другие проблемы: я заметил, что при автоматическом заполнении DataGrid в результирующую таблицу добавляются атрибуты, которые мне не обязательно нужны.
Я знаю, что существует определенное количество «соглашений по поводу конфигурации», которые вы должны принять, когда полагаетесь на структуру, которая возьмет на себя некоторые из ваших утомительных обязанностей, но «соглашения» в этих случаях не являются какими-либо устоявшимися соглашениями. , а скорее ненужные дополнения.Я знаю почему идентификатор добавляет префикс, но я должен иметь возможность настраивать и отключать подобные вещи, тем более, что, будучи своего рода евангелистом веб-стандартов, я все равно не дублирую идентификаторы HTML на одной странице.
Итак, вопрос для тех разработчиков ASP.NET, которые более опытны, чем я:исходя из вашего опыта разработки и развертывания приложений, как вы используете эти элементы управления?Вы снова прибегаете к жестко закодированному HTML?Используете ли вы смесь?Я не хочу разрабатывать свой HTML с учетом особенностей этих элементов управления, но, если возможно, я хотел бы использовать их, когда это возможно.
Что делать мальчику?
Решение
Лично,
Я думаю, что стандартные элементы управления ASP.NET подходят для внутренних задач - в этом сценарии хороши быстрые и грязные.Но однажды я работал с веб-разработчиком, который также был дизайнером, и он отказался использовать элементы управления ASP.NET и писал только код в HTML и добавлял теги runat="server", когда это необходимо.Это было больше потому, что он хотел точно знать, как его HTML будет отображаться, и в любом случае в то время некоторые элементы управления ASP.NET не отображались в соответствии со стандартами.
Я нахожусь где-то посередине: используйте HTML там, где это уместно, а не когда нет.Вы можете использовать лучшее из обоих миров с помощью Адаптеры управления CSS
Другие советы
На самом деле я очень рад видеть, что некоторые мнения здесь совпадают с моими:ASP.NET как язык шаблонов очень плох.
Я просто хотел бы опровергнуть пару высказанных здесь замечаний (в огненном костюме!):
Дэйв Уорд упоминает о коллизиях идентификаторов — это правда, но, по моему мнению, с ними плохо справляются.Я бы предпочел видеть узлы, на которые ссылаются селекторы xpath или глубокие CSS, чем делать идентификатор фактически бесполезным, за исключением использования внутренних элементов ASP.NET, таких как clientID - это просто делает написание CSS и JS намного сложнее и бессмысленно.
Роб Купер рассказывает о том, что элементы управления являются заменой HTML, так что все в порядке (перефразируя, прости меня, Роб) — ну, это нехорошо, потому что они взяли существующий и хорошо понятный язык и сказали: «Нет, вы должны делать все по-нашему». сейчас», и их путь очень плохо реализовано.например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.
Надеюсь это поможет
@Brian, да!Вы можете в значительной степени контролировать все поведение.Рассмотрите возможность создания пользовательских элементов управления (есть три типа).Недавно я дал их обзор в своем вопросе. здесь.
Я бы сильно рекомендую проверить их, мне это безмерно помогло :)
Я тоже нахожусь в своем приключении с ASP.NET, и у меня тоже были подобные разочарования.Однако вскоре к этому привыкаешь.Вам просто нужно помнить, причина, по которой вам не придется заниматься утомительным созданием HTML, заключается в том, что элементы управления ASP.NET делают все это за вас..
В некоторой степени вы можете контролировать/настраивать эти вещи, даже если это означает наследование элемента управления и настройку вывода HTML оттуда.
Раньше мне приходилось делать это, когда некоторые элементы управления по умолчанию не проходили проверку W3C, добавляя дополнительную разметку здесь и там, поэтому я просто переопределял и редактировал по мере необходимости (исправление, которое занимало буквально пару минут).
Я бы сказал, узнайте, как работает система управления..Затем соберите несколько самостоятельно, это действительно помогло мне понять, что происходит под капотом, поэтому, если у меня возникнут какие-либо проблемы, у меня есть идея, куда обращаться.
HTML отображается с такими идентификаторами, потому что это способ ASP.NET предотвратить конфликты идентификаторов.Каждый элемент управления контейнера, такой как главная страница или элемент управления мастера, добавляет «ID_» к своим дочерним идентификаторам.
В случае с вашим маркированным списком ListView обеспечивает хорошую золотую середину.Вы по-прежнему можете привязать его к источнику данных, но это дает вам гораздо более жесткий контроль над отображаемым HTML.У Скотта Гу есть хорошее введение в ListView:
Если префикс идентификатора, добавленный 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, посмотрите АСП.NET MVC вместо.
