Должен ли я создать серверный элемент управления JQuery для ASP.net, чтобы наилучшим образом использовать его в моих приложениях?

Question

Я довольно успешно продвигал JQuery в своей организации. Не маленький подвиг сам по себе. Тем не менее, одна из идей, которые будут реализованы здесь, чтобы сделать его частью нашего приложения, заключается в создании серверного элемента управления ASP.net. (Мы будем придерживаться WebForms в обозримом будущем.)

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

Мои вопросы:

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

Answer 1

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

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