Новая парадигма программирования клиентских сценариев, известная как не' навязчивый JavaScript'код (unobtrusive JavaScript), получила широкое распро_странение в сообществе разработчиков веб_приложений. Как следует из назва_ ния, данная парадигма утверждает, что JavaScript_код не должен привлекать к себе внимание, т. е. он не должен «навязываться».1 JavaScript_код не должен
1 Слово «навязывать» в некотором смысле можно считать синонимом слова «зло_ употреблять». Цитата из толкового словаря «The American Heritage dictionary»: «Навязываться … другим с неуместной настойчивостью или без приглашения».
13.1. Среда веб*броузера
навязываться пользователям, просматривающим веб_страницы, авторам, соз_ дающим HTML_разметку, или веб_дизайнерам, разрабатывающим HTML_шаб_ лоны или CSS_таблицы.
Нет строгих правил, которых следовало бы придерживаться при создании нена_ вязчивого JavaScript_кода. Однако ряд полезных приемов, обсуждаемых в раз_ ных местах этой книги, укажут вам верное направление.
Основная цель парадигмы ненавязчивого JavaScript_кода – отделить программ_ ный код от HTML_разметки. По сути, хранить содержимое отдельно от поведе_ ния – все равно, что хранить CSS_таблицы во внешних файлах, т. е. отделять со_ держимое от представления. Для достижения этой цели весь JavaScript_код дол_ жен быть вынесен в отдельные файлы, которые следует подключать к HTML_ страницам с помощью тега <script src=> (подробнее см. раздел 13.2.2). Если под_ ходить еще более строго к разделению содержимого и поведения, можно даже не включать JavaScript_код в атрибуты обработчиков событий в HTML_файле. Вме_ сто этого можно написать JavaScript_код в виде отдельного файла, который бу_ дет регистрировать обработчики событий в необходимых HTML_элементах (о том, как это делается, рассказывается в главе 17).
Как следствие этого, необходимо стремиться делать внешние файлы с Java_ Script_кодом настолько модульными, насколько это возможно, используя мето_ ды, описанные в главе 10. Это даст возможность подключать массу независимых модулей к одной и той же веб_странице, не беспокоясь о том, что переменные и функции одного модуля перекроют переменные и функции другого.
Вторая цель ненавязчивого JavaScript_кода состоит в том, чтобы возможные ог_ раничения функциональности не слишком сказывались на возможностях самой страницы. Сценарии должны задумываться и разрабатываться как расширения к HTML_содержимому, при этом само содержимое должно быть доступно для просмотра и без JavaScript_кода (например, когда пользователь отключает в бро_ узере режим исполнения JavaScript_кода). Важное место здесь занимает методи_ ка, которая называется проверкой возможностей (feature testing): прежде чем предпринять какое_либо действие, JavaScript_модули должны убедиться, что функциональные особенности, требуемые для выполнения этого действия, дос_ тупны в броузере, на котором исполняется сценарий. Методика проверки воз_ можностей более подробно описывается в разделе 13.6.3.
Третья цель ненавязчивого JavaScript_кода состоит в том, чтобы не сделать HTML_страницу менее доступной (в идеале она должна стать более доступной). Ес_ ли включение JavaScript_кода делает обращение с веб_страницей более сложным, такой JavaScript_код будет мешать пользователям с ограниченными возможно_ стями, для которых простота доступа имеет важное значение. Более подробно те_ ма обеспечения доступности средствами JavaScript описывается в разделе 13.7.
Другие формулировки ненавязчивого JavaScript_кода могут включать иные це_ ли в дополнение к трем перечисленным. Основным источником сведений о нена_ вязчивом JavaScript_кода является документ «The JavaScript Manifesto», опуб_ ликованный проблемной группой DOM Scripting Task Force по адресу http:// domscripting.webstandards.org/?page_id=2.
