Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Технологии разработки Internet-приложений. Учебное пособие
.pdf
7. ВВЕДЕНИЕ В ТЕХНОЛОГИЮ AJAX
План
7.1. Структура и история развития технологии AJAX.
7.2. Объект XmlHttpRequest.
7.3. Безопасность AJAX-приложений.
7.4. Инструментарий разработки AJAX-приложений.
7.5. Разработка мобильных Web- приложений
На данный момент развития информационных технологий
требуется усовершенствованная и более мощная платформа, построенная по традиционным принципам и правилам проектирования Web-приложений, – необходим настоящий сдвиг парадигмы.
AJAX воплощает новую парадигму для следующего поколения
Web-приложений, и, скорее всего, этой парадигме суждено оста-
ваться с нами как минимум в течение ближайшего десятилетия.
Сокращение AJAX происходит от слов «Asynchronous JavaS-
cript and XML» («асинхронный код JavaScript и ХМL»). Этим общим термином обозначаются высокоинтерактивные приложения,
быстро реагирующие на действия пользователя, выполняющие
большую часть работы на стороне клиента и взаимодействующие с
сервером посредством внеполосных обращений. Внеполосным
(out-of-band) обращением называется запрос к серверу, который
приводит к оперативному обновлению страницы (вместо ее замены). В результате Web-приложения на базе AJAX обычно в большей степени напоминают классические приложения Microsoft
Windows, поддерживают перетаскивание и асинхронные операции,
быстро реагируют на действия пользователя, не мигают при перерисовке и не раздражают пользователя.
Если взглянуть на ситуацию с точки зрения разработчика,
термином AJAX обозначается совокупность компонентов разработки, инструментов и методов создания высокоинтерактивных
Web-приложении.
В соответствии с парадигмой AJAX, Web-приложения в про-
цессе работы обмениваются с Web-сервером данными. Актуальность проблемы заключается в следующем:
1) для конечного пользователя, использование AJAX-
приложений, это более быстрое получение обновленных данных;
81
2) существенное ускорение загрузки н обновления страниц.
Web-приложения приближаются к классическим приложени-
ям Microsoft Windows, поддерживают перетаскивание и асинхронные операции, быстро реагируют на действия пользователя, не мигают при перерисовке и не раздражают пользователя.
7.1. Структура и история развития технологии AJAX
AJAX – это коллекция технологий, существующих с момента
появления Web. А вот и возможности, предоставляемые AJAX
(как это представил Джис Джеймс Гаррет (Jesse James Garrett), он
первым ввел термин «AJAX» для асинхронного JavaScript + XML):
- стандартно-базированная презентация с использованием
XHTML и CSS;
- динамическое отображение и взаимодействие с использова-
нием объектной модели документа;
- взаимообмен данными и манипуляция с задействованием
XML и XSLT;
- асинхронное извлечение данных с использованием
XMLHttpRequest;
- JavaScript, связывающий все вместе.
AJAX позволяет писать быстрореагирующие веб-приложения,
в которых не нужно постоянно обновлять страницы. AJAX – простая технология, поддерживаемая всеми основными браузерами.
Как можно вкратце отметить, единственным предварительным
условием для внедрения AJAX является знание JavaScript.
AJAX – это подход к построению интерактивных пользовательских интерфейсов веб-приложений, заключающийся в «фоновом» обмене данными браузера с веб-сервером. В результате при
обновлении данных веб-страница не перезагружается полностью,
и веб-приложения становятся более быстрыми и удобными.
AJAX – это не самостоятельная технология, а концепция использования нескольких смежных технологий. AJAX базируется
на двух основных принципах:
а) использование технологии динамического обращения к
серверу «на лету», без перезагрузки всей страницы полностью,
например:
1) с использованием XMLHttpRequest (основной объект);
2) через динамическое создание дочерних фреймов;
82
б) через динамическое создание тега <script>;
в) использование DHTML для динамического изменения содержания страницы.
В качестве формата передачи данных обычно используются
JSON или XML.
Впервые термин AJAX был публично использован 18 февраля
2005 года в статье Джесси Джеймса Гарретта «Новый подход к
Web-приложениям». Гарретт придумал термин, когда ему пришлось как-то назвать новый набор технологий, предлагаемый им
клиенту.
AJAX стал особенно популярен после использования его компанией Google в сервисах Gmail, Google Maps и Google Suggest.
Исходная инфраструктура – простая, универсальная и эффективная – стала определяющим фактором стремительного успеха
модели веб приложений. Следующее поколение Web-приложений
по-прежнему будет базироваться на HTTP и страницах, однако
содержимое страниц и возможности оборудования, работающего
на стороне сервера, существенно изменятся. В результате впечатление от работы с Web-приложениями заметно изменится – последние приблизятся к классическим Windows-приложениям для
настольных систем.
Работа сегодняшних Web-приложений основана на отправке
форм, заполненных пользователем, на Web-сервер и последующем
отображении разметки, возвращенной сервером. При обмене данными между браузером и сервером используется классический
протокол HTTP. Как известно, HTTP относится к числу протоколов без состояния; иначе говоря, каждый запрос никак не связан с
предыдущим, а автоматическое сохранение информации состояния отсутствует (объекты состояния, известные всем нам, например, по ASP.NET, представляют собой абстракцию, реализуемую
средой серверного программирования).
Обмен данными между браузером и Web-сервером происходит при помощи форм. С точки зрения пользователя пересылка
осуществляется постранично. Каждое действие пользователя, в
результате которого серверу отправляется новый запрос, приводит
к пересылке и отображению совершенно новой страницы (или измененной версии текущей страницы).
83
На основании URL, введенного в строке адреса, браузер отображает страницу. Страница, в конечном счете, состоит из разметки
HTML и содержит одну или несколько форм HTML. Пользователь
вводит данные, а затем приказывает браузеру отправить форму по
URL, заданному для этой цели (URL действия).
Браузер преобразует заданный URL в IP-адрес и открывает сокет. Пакет HTTP, содержащий форму вместе со всеми полями, пересылается по каналу связи заданному получателю. Веб-сервер принимает запрос и обычно передает его внутреннему модулю для дальнейшей обработки. В конце процесса создается пакет ответа HTTP,
а возвращаемое браузером значение вставляется в тело пакета.
Получив запрос, например, на ресурс .aspx, Web-сервер передает его подсистеме ASP.NET для обработки и получает разметку
HTML. Сгенерированная разметка включает все теги классической
страницы HTML (<html>, <body>, <form> и т. д.). Исходный код
страницы встраивается в ответ HTTP и помечается соответствующим типом MIME, чтобы браузер знал, как его следует обработать. В зависимости от типа MIME браузер выбирает дальнейшие
действия.
Если ответ содержит страницу HTML, браузер полностью заменяет текущее содержимое новой разметкой. Во время обработки
запроса сервером на экране отображается «старая» страница. Как
только «новая» страница будет полностью загружена, браузер стирает изображение и выводит ее.
Описанная модель хорошо работала в начале эпохи Web, когда содержимое Web-страниц ограничивалось форматированным
текстом, гиперссылками и небольшим количеством графики. Из-за
успеха Web пользователи становились все более требовательными,
а это заставляло разработчиков и дизайнеров создавать все более
сложный сервис и графику.
В результате страницы становятся тяжелыми и громоздкими –
даже если упорно говорить о «расширенной функциональности»,
от этого ничего не изменится.
При действующей архитектуре Web-приложений каждое действие пользователя требует полной перерисовки страницы. Как
следствие, более тяжелые («широкофункциональные») страницы
медленнее воспроизводятся на экране, а их прорисовка сопровождается мерцанием. При большом наборе страниц крупного прило-
84
жения (например, портала) такой механизм лишь вызовет раздражение у конечного пользователя.
Хотя для построения страницы на сервере разработчик может
воспользоваться целым рядом гибких архитектур, с точки зрения
клиента Web-страницы изначально проектировались в расчете на
статичность и отсутствие изменений. В конце 1990-х годов этот
основополагающий факт изменился: сначала появился стандарт
Dynamic HTML, затем модель объекта документа W3C (World
Wide Web Consortium). В наши дни страница, отображаемая брау-
зером, может модифицироваться с учетом изменений, вносимых
исключительно на стороне клиента, в зависимости от действий
пользователя.
Стандарт Dynamic HTML стал серьезным шагом вперед, но
одного его было недостаточно для качественного изменения Web.
Перерисовку страниц было необходимо свести к минимуму.
Для этой цели около 1997 года появились первые примитивные
формы сценарного удаленного вызова процедур (RPC, Remote Procedure Call). В частности, компания Microsoft со своей технологией RS (Remote Scripting) стала одним из новаторов в этой области.
В RS, для получения данных с удаленного URL, были задействованы апплеты Java. URL предоставлял формализованный программный интерфейс и сериализацию данных, пересылаемых в обе
стороны в строковом формате. На стороне клиента компактная
инфраструктура JavaScript принимала данные и активизировала
функцию обратного вызова, определяемую пользователем, для обновления пользовательского интерфейса средствами Dynamic
HTML или аналогичными методами. Технология RS работала в
Microsoft Internet Explorer 4.0, Netscape Navigator 4.0 и последую-
щих версиях.
Позднее компания Microsoft заменила апплет Java объектом
СОМ с именем XmlHttpRequest и сняла большинство ограничений
программного интерфейса, предоставляемого удаленным URL.
7.2. Объект XmlHttpRequest
В то же время появился ряд аналогичных прикладных сред,
которые должны были поднять технологию RS на новый уровень и
расширить область ее практического применения. Апплет Java исчез и был заменен объектом XmlHttpRequest.
85
В AJAX-приложениях сочетаются два противоречивых фак-
тора. С одной стороны, приложение должно передавать пользователям свежие данные, полученные с сервера. С другой стороны,
новые данные должны интегрироваться в существующую страницу без ее полного обновления.
Браузер обычно выдает новый запрос при отправке формы
HTML, инициированной либо сценарием, работающим на стороне
клиента, либо действием пользователя (скажем, щелчком на кнопке). Получив ответ, браузер заменяет старую страницу новой. На
рис. 7.1 наглядно показана традиционная схема работы вебприложений.
Рисунок 7.1. Браузер отправляет форму HTML
и получает новую страницу, отображаемую на экране
Основным фактором, заложенным в основу удаленного исполнения сценариев, является возможность выдачи внеполосных запросов HTTP. В данном контексте под внеполосным вызовом понимается запрос HTTP, который выдается за пределами встроенного модуля,
обеспечивающего отправку форм HTTP (то есть вне традиционного
механизма, показанного на рисунке 1). Внеполосный вызов инициируется событием страницы HTML и обслуживается компонентом-
посредником (proxy component). В новейших AJAX-решениях таким
посредником является объект XmlHttpRequest; в самых первых реа-
лизациях RS им был апплет Java.
Компонент-посредник (например, объект XmlHttpRequest) отправляет обычный запрос HTTP и дожидается (синхронно или
86
асинхронно) завершения его обработки. Получив готовые данные
ответа, посредник вызывает функцию обратного вызова JavaScript;
эта функция должна обновить все части страницы, нуждающиеся в
обновлении. На рис. 7.2 показано графическое представление этой
модели.
Рисунок 7.2. Внеполосные вызовы обслуживаются компонентом-
посредником, а функция обратного вызова JavaScript обновляет
все части страницы, зависящие от полученных данных
Любой браузер умеет заменять старые страницы новыми, однако не все браузеры поддерживают объектную модель, представляющую текущее содержимое страницы. В браузерах с поддержкой обновляемой объектной модели функция обратного вызова
JavaScript может обновить отдельные части старой страницы, не
требуя ее полной перезагрузки.
Спецификация DOM (Document Object Model) определяет общий интерфейс обновления содержимого, структуры и стиля документов HTML и XML, не зависящий от языка и платформы.
Стандарт DOM получил признание и был ратифицирован комитетом W3C, поэтому сейчас он поддерживается все большим количеством браузеров. DOM определяет стандартный набор объектов
для представления элементов, образующих документы HTML и
XML. Совокупность этих объектов образует стандартный интерфейс для работы с элементами страниц HTML, или на более общем уровне – документов XML.
Следует заметить, что хотя первые работоспособные прикладные среды удаленного исполнения сценариев появились около десяти
лет назад, ограниченная поддержка динамического изменения отоб-
87
ражаемого документа в браузере тормозила массовое принятие таких
технологий в масштабах отрасли. До сегодняшнего дня.
Как видно из рисунка 7.2, модель AJAX предъявляет два ключевых требования к браузеру: наличие компонента-посредника и
поддержка обновляемой модели DOM. В течение долгого времени
оба требования выполнялись только передовыми, элитными браузерами (также часто встречается термин «широкофункциональный
браузер»). За прошедшие годы только компании, способные жестко контролировать возможности клиентских браузеров, могли выбрать модель AJAX для своих сайтов. Слишком долго термин
«широкофункциональный» подразумевал «редко встречающийся»,
и для большинства коммерческих отраслей такие браузеры определенно не подходили. Впервые сложилась ситуация, когда широкофункциональный браузер перестал быть синонимом браузера с
ограниченным кругом пользователей. Проектирование высокоинтерактивных Web-приложений, реализующих методы удаленного
исполнения сценария, перестало быть недостижимой мечтой и
стало совершенно реальным делом.
Каждая платформа и каждая фирма-разработчик предлагает
собственную прикладную среду и инструментарий, но это не изменяет основополагающего факта – реализация стиля AJAX стала
возможной в 90% существующих браузеров. Это настоящий прорыв, благодаря которому сегодня можно создавать и распространять приложения, невозможные вчера.
В настоящее время стандарт обновляемой модели DOM был
ратифицирован комитетом W3C. Стандарт W3C для компонентапосредника пока находится в стадии разработки. Он воплощен в
форме объекта XmlHttpRequest и представляет собой интерфейс,
предоставляемый браузером и позволяющий сценарному коду выполнять клиентские функции HTTP – такие, как отправка данных
формы или загрузка данных с удаленного Web-сайта.
Также браузер должен поддерживать JavaScript и желательно
CSS (каскадные таблицы стилей, Cascading Style Sheets). Выходит,
что стиль AJAX доступен практически для любого разработчика и
для 90% аудитории Web, независимо от платформы. Инструменты,
необходимые для работы AJAX, получили такое же повсеместное
распространение, как парсеры HTML/XML и обработчики JavaS-
cript. Перефразируя лозунг популярной рекламной кампании,
88
можно сказать: «AJAX здесь и сейчас!» А в том, что касается Windows и платформы ASP.NET, AJAX воплощается в форме
Microsoft Atlas.
Объект XmlHttpRequest впервые появился в Internet Explorer
5.0. Этот внутренний объект публикуется браузером для работы с
его подсистемой исполнения сценариев. Сценарный код, входящий в клиентскую страницу (как правило, код JavaScript), обращается к объекту и использует его функциональность.
Что касается функциональности (несмотря на префикс XML),
объект XmlHttpRequest представляет собой компактную объектную модель для отправки сценарием обращений HTTP в обход
браузера. Когда пользователь щелкает на кнопке отправки формы
или выполняет любое действие, приводящее к вызову метода sub-
mit объекта form модели DOM, браузер вмешивается в происходящее и берет последующую отправку запроса HTTP под свой
полный контроль. С точки зрения пользователя, отправка запроса
работает по принципу «черного ящика» с единственным видимым
результатом: на экране появляется новая страница. Клиентский
код сценария не может управлять процессом размещения и результатом отправки запроса.
Объект XmlHttpRequest дает возможность сценарному коду
отправлять запросы HTTP и обрабатывать полученные ответы.
Объект XmlHttpRequest, созданный компанией Microsoft и
вскоре принятый в Mozilla, поддерживается большинством Webбраузеров. Его реализация в значительной мере зависит от браузера, хотя интерфейс верхнего уровня остается практически неизменным. По этой причине комитет W3C в настоящее время работает над точным описанием минимального набора общих возможностей, основанного на существующих реализациях.
В то время, когда появился объект XmlHttpRequest, в мире
господствовала модель COM (Component Object Model), разработанная компанией Microsoft. Модель расширяемости программных
продуктов и приложений базировалась на технологии СОМ и реализовывалась с использованием компонентов СОМ. В конце 1990х годов было совершенно правильно и естественно реализовать
новый компонент в виде объекта автоматизации СОМ, которому
было присвоено имя Microsoft.XmlHttp.
89
За последующие годы были выпущены разные версии того же
компонента (даже со слегка различающимися именами), но во всех
случаях исходная модель компонента оставалась неизменной –
СОМ. Например, в Internet Explorer 6.0 объект XmlHttpRequest поставляется в форме объекта СОМ.
Объекты СОМ представляют собой внешние компоненты, для
выполнения которых в браузере необходимо специальное разрешение. В частности, для инициализации объекта XmlHttpRequest и
последующего использования любой функциональности AJAX,
построенной на его базе, клиентский компьютер должен принимать компоненты ActiveX,
Несомненно, компонент XmlHttpRequest безопасен. Но чтобы
использовать его, пользователь должен понизить общий уровень
безопасности и принять все остальные компоненты, объявленные
«безопасными» для использования в сценариях, во всех посещаемых Web-сайтах.
Объект XmlHttpRequest предназначен для выполнения одной
ключевой операции: отправки запросов HTTP. Запросы могут отправляться как синхронно, так и асинхронно.
Операции с компонентом выполняются в два этапа. Сначала
открывается канал к URL, выбирается метод (GET, POST и т. д.) и
указывается, должен ли запрос быть отправлен асинхронно. На
втором этапе задаются все необходимые заголовки, а запрос отправляется серверу. Если для запроса используется метод POST,
методу send передается тело запроса.
При выполнении асинхронных операций метод send немед-
ленно возвращает управление. Написанная функция onread-
ystatechange должна проверить состояние текущей операции и
определить момент ее завершения.
Ответ доступен в двух форматах – физического текста и документа XML.
Для Web-страницы, выдающей внеполосные вызовы, определяется одно или несколько триггерных событий, которые в результате обработки кодом JavaScript выдают запросы через объект
XmHttpRequest. Триггерными событиями могут быть только события HTML, отслеживаемые реализацией DOM текущего браузера.
Правильное отображение результатов в большинстве браузеров – задача не из простых. Так, модель DOM в Internet Explorer под-
90
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]