Управление по сравнению со стандартным HTML
Я попадаю в ASP.NET(С# - я знаю, что это не имеет значения для этого конкретного вопроса, но полное раскрытие и все такое), и хотя мне очень нравится, что элементы управления asp:
утомительной HTML-обработки, меня часто разочаровывает определенное поведение. Однажды ночью я столкнулся с работой с основными страницами: мой <asp:BulletedList ID="nav">
, преобразованный в HTML, стал <ul id="ct100_nav">
.
Существуют и другие проблемы. Я заметил, что при автоматическом заполнении DataGrid он добавляет атрибуты к полученной таблице, которые мне не нужны.
Я знаю, что существует определенная "конвенция над конфигурацией", которую вы должны принять, когда полагаетесь на структуру, чтобы взять на себя некоторые из ваших утомительных обязанностей, но "соглашения" в этих случаях не так много любых установленных конвенций, а скорее ненужных дополнений. Я знаю, почему идентификатор добавляет префикс, но я должен уметь настраивать и отключать такие функции, особенно, поскольку, как немного евангелист веб-стандартов, я все равно не дублировал HTML-идентификатор на одной странице.
Итак, вопрос здесь для тех разработчиков ASP.NET, которые были более опытными, чем я: в своем опыте разработки и развертывания приложений, как вы используете эти элементы управления? Вы возвращаетесь к жестко закодированному HTML? Вы используете смесь? Я не хочу создавать свой HTML-код вокруг уникальных причуд в этих элементах управления, но, если возможно, я бы хотел использовать их, когда это возможно.
Что делать мальчику?
Ответы
Ответ 1
Лично
Я думаю, что стандартные элементы управления ASP.NET отлично подходят для работы на дому - быстрый и грязный в этом сценарии хорош. Но однажды я работал с веб-разработчиком, который также был дизайнером, и он отказался использовать элементы управления ASP.NET и только код в HTML и добавил теги runat = "server" при необходимости. Это было больше, потому что он хотел точно знать, как его HTML будет отображаться, и в то время в любом случае некоторые из элементов управления ASP.NET не будут соответствовать стандарту соответствия.
Я сижу где-то посередине - используйте HTML, где это необходимо, а не когда нет. Вы можете выбрать лучшее из обоих миров с помощью Адаптеры управления CSS
Ответ 2
На самом деле я очень рад видеть некоторые мнения, соглашающиеся с моим: ASP.NET как язык шаблонов очень низок.
Я просто хотел бы опровергнуть пару про-очков, сделанных здесь (пламя на!):
Дэйв Уорд упоминает столкновения с ИД - это правда, но я так плохо справился. Я бы предпочел видеть узлы, на которые ссылаются селекторами xpath или deep css, чем сделать идентификатор эффективно бесполезным, кроме как откладывая его на внутренние элементы ASP.NET, такие как clientID - он просто делает писать CSS и JS намного труднее.
Роб Купер рассказывает о том, как элементы управления заменяют HTML, так что все прекрасно (перефразируя, прощай мне Роб) - хорошо это не хорошо, потому что они взяли существующий и хорошо понятый язык и сказали "нет, ты должен сделать вещи наши пути сейчас", и их путь очень плохо реализован. например asp: panel отображает таблицу в одном браузере и div в другом! Без документации или выполнения разметка для элемента управления входами (и многих других) не предсказуема. Как вы собираетесь заставить дизайнера писать CSS против этого?
Espo пишет о том, как элементы управления дают вам преимущества абстракции, если платформа изменяет html - ну это ясно круговое (это меняется только потому, что платформа меняется, и не понадобится, если бы у меня был только собственный HTML-код вместо этого) и фактически создает проблему. Если элемент управления снова изменится с обновлением, как мой CSS должен справиться с этим?
Апологи скажут "да, но вы можете изменить это в конфиге" или поговорите о переопределении элементов управления и пользовательских элементов управления. Ну зачем мне это нужно? Комбинированный пакет управления css, предназначенный для исправления некоторых из этих проблем, - это что-то, кроме как с нестандартной разметкой, и это не касается проблемы с идентификатором.
Невозможно реализовать MVC (абстрактная концепция, а не реализация 3.5) из коробки с веб-приложениями, потому что эти элементы управления так сильно привязывают представление и управление. Там есть барьер входа для традиционного веб-дизайнера, потому что он должен взаимодействовать с кодом на стороне сервера, чтобы реализовать то, что раньше было отдельными доменами CSS и JS. Я сочувствую этим людям.
Я полностью согласен с точкой Киви, что элементы управления позволяют очень быстро развиваться для приложений определенного профиля, и я согласен с тем, что по какой-то причине некоторые программисты находят HTML неприятным, и, кроме того, преимущества других частей ASP.NET дать вам, который требует этих средств контроля, может стоить того.
Однако я не согласен с потерей контроля, я чувствую, что модель работы с такими вещами, как классы, стили и сценарии на кодебе, - это неправильный шаг назад, и я также чувствую, что есть лучшие модели для шаблонов (реализация микроформатов и xslt для этой платформы), хотя замена элементов управления на них нетривиальна.
Я думаю, что ASP.NET может многому научиться у связанных технологий в LAMP и мире рельсов, до тех пор я надеюсь работать с 3.5 MVC, где могу.
(извините, что было так долго </rant> )
Ответ 3
Короткий ответ заключается в том, что вы никогда не должны использовать asp:... версию стандартного элемента управления HTML, если у вас нет действительно веской причины.
Младшие разработчики часто получают возможность использовать эти элементы управления, потому что они охвачены в большинстве книг ASP.NET, поэтому он предположил, что они должны быть лучше. Они не. На данный момент, после 8 лет ежедневной разработки ASP.NET, я могу только думать о 2 или 3 случаях, когда на самом деле имеет смысл использовать asp:... INPUT для стандартного HTML-кода.
Ответ 4
Что касается идентификатора на серверных элементах управления: вы можете найти фактический идентификатор, который будет записан в браузер, путем обращения к ClientID. Таким образом, вы можете комбинировать серверные скрипты на стороне клиента и все еще не должны жестко кодировать _id = "ct100_nav" _
Я всегда пытаюсь использовать включенные элементы управления вместо "взлома" HTML, потому что, если в дальнейшем будет обновление или некоторое улучшение, весь мой код по-прежнему будет работать, просто заменив фреймворк, и мне не нужно менять какие-либо HTML.
Надеюсь, что это поможет
Ответ 5
@Брайан,
Ага! Вы можете в значительной степени контролировать все поведение. Рассмотрите возможность создания пользовательских элементов управления (существует три типа). Я недавно дал обзор их в моем вопросе здесь.
Я бы настоятельно рекомендовал проверить их, помог мне не конец:)
Ответ 6
Я тоже нахожусь в своем приключении в ASP.NET и тоже испытываю подобные разочарования. Однако вы скоро привыкаете к этому. Вам просто нужно запомнить причину, по которой у вас нет утомительной обработки HTML, потому что элементы управления ASP.NET делают это для вас.
В какой-то степени вы можете контролировать/настраивать эти вещи, даже если это означает наследование элемента управления и настройку вывода HTML из него.
Мне приходилось делать это в прошлом, когда некоторые элементы управления не проходили проверку W3C по умолчанию, добавляя некоторую дополнительную разметку здесь и там, поэтому я просто переделывал и редактировал по мере необходимости (исправление, которое буквально пару минут)..
Я бы сказал, что узнал о том, как работает система управления. Затем выбивайте несколько вместе, это действительно помогло мне понять, что происходит под капотом, поэтому, если у меня возникнут какие-либо проблемы, у меня есть идея, куда идти.
Ответ 7
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
Ответ 8
Если префикс ID, добавленный ASP.NET, является проблемой для вас, чтобы получить к ним доступ позже, используя JS или что-то еще... у вас есть сторона сервера свойств .ClientID.
Если накладные расходы, добавленные ASP.NET, вы должны рассмотреть ASP.NET MVC (предварительный просмотр), где у вас есть полный контроль над испускаемым html.
Я перехожу к MVC, потому что мне не нравятся все, что добавлено тоже...
Ответ 9
Я думаю, что большинство ответов здесь имеют дизайнерскую точку зрения. В проекте от малого до среднего может показаться накладной для синхронизации кода и CSS/HTML, а также обеспечения их соответствия стандартам и чистоты. Конструкторский способ сделать это - иметь полный контроль над отображаемым HTML. Но есть много способов иметь полный контроль над ASP.NET. И для меня наличие требуемого HTML в файле aspx/ascx является самым немасштабируемым и грязным способом сделать это. Если вы хотите стилизовать элементы управления с помощью CSS, вы всегда можете установить серверную часть класса через свойство CssClass. Если вы хотите получить к ним доступ через JS, вы можете снова запустить JS с правильными идентификаторами на стороне сервера. Единственным недостатком, который это обеспечивает, является то, что разработчик и разработчик должны работать вместе. В любом крупном проекте это неизбежно. Но преимущества ASP.NET намного превосходят эти трудности.
Тем не менее, если вы хотите стандартизированный HTML, поддержку скинов и другие полезные свойства для управления отображаемой разметкой, вы всегда можете использовать элементы управления thrid-party.
Ответ 10
Как уже упоминал Дейв Уорд, "это способ ASP.NET предотвращения столкновений с идентификаторами".
Очень хороший пример: если вы пытаетесь поместить элемент управления внутри настраиваемого элемента управления, используйте этот настраиваемый элемент управления в ретрансляторе, так что пользовательский элемент управления HTML будет выводиться несколько раз для страницы.
Как уже упоминалось, если вам нужно получить доступ к элементам управления для javascript, используйте свойство ClientScript, которое даст вам доступ к ClientScriptManager и зарегистрирует ваши сценарии на странице таким образом. Убедитесь, что при написании сценариев использовать свойство ClientID в элементе управления, который вы пытаетесь ссылаться, вместо ввода идентификатора элемента управления.
Ответ 11
Если вам нужен такой контроль над отображаемым HTML, вместо этого просмотрите ASP.NET MVC.