Блог

Я довольно успешно продвигаю jQuery в своей организации. Сам по себе немалый подвиг. Тем не менее, одна из идей, которые обсуждаются здесь, чтобы сделать его частью нашего приложения, состоит в том, чтобы создать ASP.net управление на стороне сервера. (В обозримом будущем мы будем придерживаться веб-форм.)

Я не слишком в восторге от этого подхода, так как он кажется излишним, когда пара тегов скрипта справится с этой задачей. Мы нашли статью в Интернете, и объем задействованного кода, похоже, себя не оправдывает. Тем не менее, я слышал, что есть некоторая выгода в кэшировании или генерации сценариев, которые происходят с серверными элементами управления.

Мои вопросы:

• Кто-нибудь еще написал ASP.net серверный контроль для обслуживания j-кода jQuery?
• Кто-нибудь еще думает, что это сумасшедшая идея-просто избегать написания кода jQuery или Javascript?

Я знаю, что Microsoft (наряду с Nokia) «внедряет» jQuery и будет интегрировать его с будущими версиями Visual Studio. Возможно, вы захотите узнать, как они будут официально использовать его, чтобы вы могли настроить свои настройки сейчас и, надеюсь, облегчить свой переход на «официальный MS jQuery» в будущем.

Я согласен с вами. Не стоит тратить время на создание и накладные расходы на создание элемента управления для добавления местоположения скрипта jQuery.

Лучшим решением было бы иметь файл 1 .js, содержащий все ссылки, необходимые для загрузки на страницу. Это может устранить множество ссылок .js, если в этом проблема с командой.

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

Одна из причин использования серверного элемента управления для введения ссылки на JavaScript заключается в том, что проще контролировать, какие файлы JavaScript добавляются на страницу. Представьте себе сценарий, в котором вы используете ядро jQuery, плюс пользовательский интерфейс jQuery и несколько других плагинов. В зависимости от того, как вы закодировали этот элемент управления, вы можете позволить разработчику легко выбирать, какие функции необходимы для конкретной страницы, не беспокоясь о конкретных необходимых сценариях. Этот подход позволит вам значительно гибче сегментировать ваше приложение: например, серверный элемент управления может использоваться главными страницами, дочерней страницей, пользовательскими элементами управления или другим серверным элементом управления. Если главная страница зарегистрировала требование для одной библиотеки jQuery, но дочерняя страница или один из пользовательских элементов управления требуют дополнительных библиотек, то наличие единого API упрощает это. Лично я считаю, что лучше всего с этим справляется вспомогательная библиотека, а не серверный элемент управления.

Суть в том, насколько вы хотите, чтобы каждый разработчик заново изобрел колесо или использовал общий, простой в использовании API, который обеспечивает единообразие ваших приложений.

Я нашел сообщение в блоге Скотта Хансельмана с образцом приложения, в котором ASP.net AJAX jQuery. Это простое приложение, но оно включает в себя весь javascript с тегами сценариев. Я не вижу никакого смысла использовать серверный элемент управления для обслуживания сценариев.