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

Question

Я вхожу в ASP.NET (C # - я знаю, что это не имеет значения для этого конкретного вопроса, но полное раскрытие и все такое), и хотя мне нравится, что элементы управления в стиле asp: спасут меня много из утомительного создания HTML, я часто расстраиваюсь определенным поведением. Однажды вечером я столкнулся при работе с мастер-страницами: мой <asp:BulletedList ID="nav"> при преобразовании в HTML стал <ul id="ct100_nav">.

Существуют и другие проблемы - я заметил, что при автоматическом заполнении DataGrid в результирующую таблицу добавляются атрибуты, которые мне там не обязательно нужны.

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

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

Что делать мальчику?

Answer 1

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

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

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

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

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

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

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

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

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

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

(извините, что так долго )

Answer 2

Лично

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

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

Answer 3

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

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

Answer 4

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

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

Answer 5

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

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

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

Answer 6

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

Answer 7

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

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

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

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

Answer 8

Если вы хотите так много контролировать визуализированный HTML, посмотрите вместо этого ASP.NET MVC .

Answer 9

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

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

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

Answer 10

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