Ajax под прицелом
Технология Ajax и это модное «Web 2.0» уже несколько лет у всех на слуху. Разумеется, в Сети по данной теме написано немало, есть и заслуживающие внимания и изучения материалы. Я не буду вдаваться в описание технических подробностей. Я хочу обсудить «идеологические» вопросы использования Ajax. Поэтому, если раньше об Ajax'е вы ничего не слышали, ознакомьтесь со статьями, ссылки на которые приведены в конце этой заметки. В них есть как теория, так и практические примеры.
Модель «клиент-сервер»
Фактически единственной моделью построения приложений для
интернета является модель
Перед обсуждением возможностей технологии Ajax рассмотрим традиционные
методы построения
Следует отметить, что клиентская часть
Принципиальный недостаток классического
Рассмотрим подробнее составляющие этой технологии и их особенности.
JavaScript
Несмотря на ажиотаж вокруг Ajax и Web 2.0, ничего
революционного в них нет. Название Ajax — это сокращение от Asynchronous JavaScript and XML. Почти всегда под этим
подразумевается использование объекта XMLHttpRequest для формирования запроса к серверу и приема ответа.
В некоторых источниках сообщалось, что выполнить
Справедливости ради стоит отметить, что есть и другие способы получения данных без перезагрузки страницы, но объект XMLHttpRequest для этих целей наиболее удобен.
JavaScript также используется для отображения принятой информации, отслеживания действий пользователя и реагирования на них.
XML
В большинстве статей, попадавшихся мне, рассматривалась
передача данных исключительно в формате XML. Однако в некоторых статьях (например, в цикле [1] вопросу об
использовании XML в Ajax посвящена отдельная статья) совершенно справедливо
поднимается вопрос о разумности подобного подхода. Действительно, пусть для
работы с объектами, имеющими большое количество свойств, на странице есть форма,
каждое поле ввода которой соответствует определенному свойству. Мы можем
передать данные на сервер либо в формате XML <свойство N>значение N</свойство N>, либо парами свойство N = значение N, либо еще
Иногда стремление использовать XML где только можно доводит до абсурда. В недавно купленной книге AJAX и PHP (справедливости ради стоит отметить, что ничего нового по рассматриваемой теме я оттуда не узнал, меня заинтересовала глава этой книги об SVG и Ajax) был приведен пример создания XML на PHP при помощи API DOM. Я совсем не понимаю, зачем использовать DOM при создании XML, когда это можно сделать работой со строками и оператором вывода echo (выполняется быстрее и запрограммировать легче).
Для передачи данных клиенту можно, конечно, представить их в XML и отправить ему, на
стороне клиента разобрать (благо, в JavaScript для этого можно построить дерево DOM для принятого XML и обойти его) и, наконец, заполнить
полученными значениями поля формы. Однако проще передать целиком
Единственная цель, для достижения которой использование XML оправдано, это обеспечение кроссплатформенности, когда к одному серверному приложению должны обращаться разные клиенты, возможно, написанные разными программистами.
Асинхронность
Под асинхронностью в данном случае понимается возможность приложения отправить запрос на сервер и продолжить работу, не дожидаясь ответа. Потом, когда ответ придет, можно его обработать и определенным образом на него отреагировать.
Практически во всех материалах про Ajax, с которыми мне приходилось сталкиваться, асинхронность преподносилась как огромное достоинство данной технологии, благодаря которому интерфейс кажется «динамичным». Естественно, это заблуждение, не зря он динамичным только кажется.
Дело в том, что интерфейсы, разрабатываемые с помощью Ajax, можно условно разделить на две группы. В первую входят интерфейсы, близкие к классическим. Это обычные формы с некоторыми дополнительными возможностями: автозаполнением, проверкой вводимой информации по мере заполнения формы. Если в браузере отключен JavaScript, работоспособность таких интерфейсов сохранится, перестанут работать только дополнительные возможности. Здесь применение асинхронных запросов оправданно и даже необходимо. Если бы после заполнения очередного поля работа приложения приостанавливалась бы до получения ответа от сервера с результатом проверки введенной информации, пользоваться таким интерфейсом было бы невозможно.
Интерфейсы из другой группы целиком построены на обращениях
к серверу и, следовательно, существенным образом используют JavaScript, без которого они работать не
будут. Здесь, наконец, можно уйти от классики и реализовать ранее недоступные
возможности, которые давно используются обычными программами, такими как Word или Windows'овский проводник. Например,
перетаскивание объектов (Drag and Drop),
отображение связей между ними и т. д. В данном случае применение асинхронных
запросов, скорее всего, приведет к путанице. Например, пусть пользователь сначала
передвинет мышкой
В данной ситуации лучше подходят синхронные запросы, когда
выполняющийся
Как видим, основное достоинство Ajax при построении интерфейсов не в том, чтобы получать ответ от сервера незаметно для пользователя (чаще всего в случайные моменты времени), а в том, чтобы сократить время отклика приложения за счет уменьшения объема передаваемой между клиентом и сервером информации.
Выводы
Объект XMLHttpRequest, составляющий основу технологии Ajax, предоставляет
Используя возможности, предоставляемые HTML и CSS,
Отмечу еще один момент. Ясно, что сайты, разрабатываемые с использованием Ajax, не
будут работать повсеместно. Нужно либо проектировать их так, чтобы они работали
и в браузере без JavaScript,
либо быть уверенным, что пользователь может установить у себя
Конечно, у обычных программ по сравнению с
Ссылки по теме
- Оcвоение Ajax — неплохой учебник по Ajax и сопутствующим технологиям.
- Ajax в Википедии и викиучебнике.
POST-запросы в Ajax- AJAX'овые грабли в Internet Explorer 6
Комментарии
К самой статье это не имеет непосредственного отношения. Тема статьи — Ajax как один из вариантов построения интерфейсов клиента. Поэтому я не стал перегружать ее ненужными деталями.
Оставьте свой комментарий