Сайт Романа ПарпалакаЗаметкиТехнологииВеб-разработкаAjax под прицелом

Ajax под прицелом

29 июля 2007 года

Технология Ajax и это модное «Web 2.0» уже несколько лет у всех на слуху. Разумеется, в Сети по данной теме написано немало, есть и заслуживающие внимания и изучения материалы. Я не буду вдаваться в описание технических подробностей. Я хочу обсудить «идеологические» вопросы использования Ajax. Поэтому, если раньше об Ajax'е вы ничего не слышали, ознакомьтесь со статьями, ссылки на которые приведены в конце этой заметки. В них есть как теория, так и практические примеры.

Модель «клиент-сервер»

Фактически единственной моделью построения приложений для интернета является модель «клиент-сервер», которая предполагает установку программных модулей у клиента и на сервере, обменивающихся информацией через сеть. Предпосылки выбора такой модели очевидны: информация хранится на сервере, а пользователь на своем компьютере может управлять этой информацией (получать с сервера, редактировать, отправлять назад и т. д.).

Перед обсуждением возможностей технологии Ajax рассмотрим традиционные методы построения веб-интерфейса. Обычно он представляет собой страницу, на которой расположена одна или несколько форм с полями ввода, флажками, переключателями и, конечно, кнопкой «Отправить». Форма заполняется пользователем; после нажатия на вышеупомянутую кнопку информация передается на сервер для обработки. Думаю, вы не раз встречали такой интерфейс, например, при регистрации на сайтах.

Следует отметить, что клиентская часть веб-приложения совсем не обязана быть веб-странией и загружаться браузером. Она может быть обычной программой, запускаемой на компьютере клиента. Наверно, наиболее известные примеры таких программ — почтовые клиенты The Bat и Outlook.

Принципиальный недостаток классического веб-интерфейса — определенные трудности при работе с большим объемом данных, которые проявляются в частых перезагрузках страниц и связанных с ними задержек. Ясно, что они являются следствием ограниченных возможностей клиентской части приложения (которая в описанном выше варианте практически отсутствует). Если бы можно было передавать данные на сервер и принимать ответ в обход перезагрузки страницы, работа интерфейса существенно ускорилась бы, так как сервер передавал бы только необходимые данные, а не всю страницу целиком. Эта идея и лежит в основе Ajax.

Рассмотрим подробнее составляющие этой технологии и их особенности.

JavaScript

Несмотря на ажиотаж вокруг Ajax и Web 2.0, ничего революционного в них нет. Название Ajax — это сокращение от Asynchronous JavaScript and XML. Почти всегда под этим подразумевается использование объекта XMLHttpRequest для формирования запроса к серверу и приема ответа. В некоторых источниках сообщалось, что выполнить POST-запрос с помощью XMLHttpRequest невозможно. Однако это не так, в [3] приведен пример того, как отправить данные формы на сервер методом POST.

Справедливости ради стоит отметить, что есть и другие способы получения данных без перезагрузки страницы, но объект XMLHttpRequest для этих целей наиболее удобен.

JavaScript также используется для отображения принятой информации, отслеживания действий пользователя и реагирования на них.

XML

В большинстве статей, попадавшихся мне, рассматривалась передача данных исключительно в формате XML. Однако в некоторых статьях (например, в цикле [1] вопросу об использовании XML в Ajax посвящена отдельная статья) совершенно справедливо поднимается вопрос о разумности подобного подхода. Действительно, пусть для работы с объектами, имеющими большое количество свойств, на странице есть форма, каждое поле ввода которой соответствует определенному свойству. Мы можем передать данные на сервер либо в формате XML <свойство N>значение N</свойство N>, либо парами свойство N = значение N, либо еще как-нибудь. Сложность (или простота) программирования на стороне клиента для двух предложенных вариантов примерно одинакова, а вот на сервере (если речь идет, например, о PHP) данные во втором варианте будут обработаны и преобразованы в переменные автоматически.

Иногда стремление использовать XML где только можно доводит до абсурда. В недавно купленной книге AJAX и PHP (справедливости ради стоит отметить, что ничего нового по рассматриваемой теме я оттуда не узнал, меня заинтересовала глава этой книги об SVG и Ajax) был приведен пример создания XML на PHP при помощи API DOM. Я совсем не понимаю, зачем использовать DOM при создании XML, когда это можно сделать работой со строками и оператором вывода echo (выполняется быстрее и запрограммировать легче).

Для передачи данных клиенту можно, конечно, представить их в XML и отправить ему, на стороне клиента разобрать (благо, в JavaScript для этого можно построить дерево DOM для принятого XML и обойти его) и, наконец, заполнить полученными значениями поля формы. Однако проще передать целиком HTML-код формы и одним оператором JavaScript выполнить всю работу. Конечно, последний способ предполагает несколько больший объем передаваемых данных, но его легче реализовать.

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

Асинхронность

Под асинхронностью в данном случае понимается возможность приложения отправить запрос на сервер и продолжить работу, не дожидаясь ответа. Потом, когда ответ придет, можно его обработать и определенным образом на него отреагировать.

Практически во всех материалах про Ajax, с которыми мне приходилось сталкиваться, асинхронность преподносилась как огромное достоинство данной технологии, благодаря которому интерфейс кажется «динамичным». Естественно, это заблуждение, не зря он динамичным только кажется.

Дело в том, что интерфейсы, разрабатываемые с помощью Ajax, можно условно разделить на две группы. В первую входят интерфейсы, близкие к классическим. Это обычные формы с некоторыми дополнительными возможностями: автозаполнением, проверкой вводимой информации по мере заполнения формы. Если в браузере отключен JavaScript, работоспособность таких интерфейсов сохранится, перестанут работать только дополнительные возможности. Здесь применение асинхронных запросов оправданно и даже необходимо. Если бы после заполнения очередного поля работа приложения приостанавливалась бы до получения ответа от сервера с результатом проверки введенной информации, пользоваться таким интерфейсом было бы невозможно.

Интерфейсы из другой группы целиком построены на обращениях к серверу и, следовательно, существенным образом используют JavaScript, без которого они работать не будут. Здесь, наконец, можно уйти от классики и реализовать ранее недоступные возможности, которые давно используются обычными программами, такими как Word или Windows'овский проводник. Например, перетаскивание объектов (Drag and Drop), отображение связей между ними и т. д. В данном случае применение асинхронных запросов, скорее всего, приведет к путанице. Например, пусть пользователь сначала передвинет мышкой какой-нибудь объект, а потом выполнит другое действие. После окончания перемещения серверу отправляется запрос. Скорее всего, ответ от сервера придет тогда, когда пользователь уже будет выполнять другое действие. Ответ этот совершенно не обязан подтвердить успешность выполнения операции. Ошибок может случиться много. И тогда нужно будет прерывать действия пользователя, сообщать ему, что предыдущая операция не была завершена (хотя интерфейс показал обратное!). Разумеется, пользователь потратит некоторое время, чтобы понять, что произошло.

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

Как видим, основное достоинство Ajax при построении интерфейсов не в том, чтобы получать ответ от сервера незаметно для пользователя (чаще всего в случайные моменты времени), а в том, чтобы сократить время отклика приложения за счет уменьшения объема передаваемой между клиентом и сервером информации.

Выводы

Объект XMLHttpRequest, составляющий основу технологии Ajax, предоставляет JavaScript-программе удобный способ для обмена данных с сервером, поэтому этот объект можно применять для построения удобных и (относительно) быстрых веб-интерфейсов.

Используя возможности, предоставляемые HTML и CSS, веб-интерфейс можно оформить в стиле традиционных программ вроде Word. Однако следует понимать, что веб-интерфейс, как клиентская часть веб-приложения, (даже с использованием Ajax) будет существенно уступать по производительности и по возможностям обычным программам. Можно сравнить для примера, хотя бы, почтовые веб-интерфейсы и уже упоминавшийся The Bat. Всё дело в том, что набор инструментов, используемый при проектировании веб-интерфейсов, изначально для этого не предназначался, поэтому он неудобен и медлителен в работе.

Отмечу еще один момент. Ясно, что сайты, разрабатываемые с использованием Ajax, не будут работать повсеместно. Нужно либо проектировать их так, чтобы они работали и в браузере без JavaScript, либо быть уверенным, что пользователь может установить у себя какой-нибудь из современных браузеров.

Конечно, у обычных программ по сравнению с веб-интерфейсами есть свои недостатки. Главный из них — такие программы необходимо предварительно установить и настроить, в то время как для работы веб-интерфейсов ничего, кроме браузера, не нужно. Именно здесь использование Ajax может стать главным аргументом в пользу веба, когда перед разработчиком встает задача построения интерфейса.

Ссылки по теме

  1. Оcвоение Ajax — неплохой учебник по Ajax и сопутствующим технологиям.
  2. Ajax в Википедии и викиучебнике.
  3. POST-запросы в Ajax
  4. AJAX'овые грабли в Internet Explorer 6
Поделиться

Комментарии

#1. 21 марта 2008 года, 10:46. Eugene пишет:
Вообще то обычно интернет приложения трехзвенные — клиент, программа на веб-сервере (например на php) и база данных (обычно MySQL).
#2. 22 марта 2008 года, 08:38. пишет:
А если программа на сервере обращается не к базе, а к файлам? Веб-приложения можно строить сколько-угодно-звенные, если на них будет большая нагрузка. Например, из четырех звеньев: клиент + nginx + PHP(CGI) + MySQL.

К самой статье это не имеет непосредственного отношения. Тема статьи — Ajax как один из вариантов построения интерфейсов клиента. Поэтому я не стал перегружать ее ненужными деталями.

Оставьте свой комментарий

Ваше имя:

Комментарий:

Для выделения используйте следующий код: [i]курсив[/i], [b]жирный[/b].
Цитату оформляйте так: [q = имя автора]цитата[/q] или [q]еще цитата[/q].
Ссылку начните с http://. Других команд или HTML-тегов здесь нет.

Сколько будет 63+7?