Крейн Д., Паскарелло Э., Джеймс Д,. AJAX в действии / Ajax в действии / ajinact / Ajax в действии
.pdf44 Часть I. Новый взгляд на Web-приложение
страницы к другой. Мы не можем влиять на задержку, связанную с взаимодействием по сети, но можем минимизировать ее влияние, обращаясь к удаленным методам в асинхронном режиме.
К несчастью, нам, разработчикам Web-приложений, не так-то просто следовать этим давно известным рекомендациям. Протокол HTTP действует по принципу "запрос-ответ". Клиент передает запрос на получение документа, а сервер отвечает, либо предоставляя требуемые данные, либо информируя о том, что он не может их найти, либо предлагая перейти по другому адресу, либо сообщая клиенту, что тот может использовать копию, содержащуюся в кэше. Протокол, в котором предусмотрено лишь взаимодействие "запросответ", является в некотором смысле "односторонним". Клиент может обратиться к серверу, но сервер по своей инициативе не может установить взаимодействие с клиентом. Более того, в промежутке между двумя последовательными запросами сервер даже не имеет сведений о клиенте.
Большинство разработчиков Web-приложений используют современные технологии, такие как Java, PHP или .NET, поскольку в них поддерживается сеанс взаимодействия. Мысль о том, что неплохо бы реализовать в серверах поддержку текущего состояния процесса взаимодействия с клиентами, пришла слишком поздно. Протокол HTTP очень хорошо выполняет те задачи, для которых он был изначально разработан, но адаптировать его для решения вопросов, которые не были предусмотрены создателями данного протокола, крайне сложно. Однако при асинхронном обращении к удаленному методу клиент должен быть оповещен дважды: при порождении потока и при его завершении. Для протокола HTTP и классических Web-приложений эта задача неразрешима.
Основой классической модели Web-приложения, подобной той, которая используется на сервере Amazon, является Web-страница. Документ, отображаемый в окне браузера, содержит набор гипертекстовых ссылок и формы, позволяющие переходить к другим документам и посылать серверу данные. Такой подход позволяет взаимодействовать с базами данных большого объема. Специалисты Amazon и других компаний накопили немалый опыт создания таких приложений и показали, что их вполне можно применять в серьезных проектах.
В процессе многолетней работы с Интернетом большинство из нас привыкли к описанной модели взаимодействия и не представляют себе альтернативы. Инструменты разработки с интерфейсом WYSIWYG формируют Webузел в виде набора Web-страниц. Переход от одной страницы, расположенной на сервере, к другой можно представить в виде диаграммы изменения состояния. Классическим Web-приложениям изначально присущи недостатки, связанные с получением отклика, и прибегнуть к асинхронной обработке не представляется возможным.
Однако компания Amazon, и не она одна, используя свой узел, успешно строит бизнес. Поэтому классические Web-приложения нельзя однозначно считать непрактичными. Чтобы понять, почему Web-страницы выполняют свои функции на сервере Amazon, а для других целей могут оказаться неприменимыми, рассмотрим различные образы использования.
Глава 1. Каким должен быть Web-интерфейс 45
/
1.1.4. Независимый и переходный образы использования
Бессмысленно спорить о том, что лучше: велосипед или спортивный автомобиль. Каждый из них имеет свои преимущества: уровень комфорта, скорость, потребление горючего. Немаловажен и тот факт, насколько конкретный вид транспорта соответствует вашему имиджу. Рассматривая конкретные образы использования, например, перемещение в час пик по центру города, организацию летнего отдыха большой семьи или поиск зонтика в дождь, можно сказать, что в каждом из них возможен безусловно успешный исход. То же справедливо и для пользовательских интерфейсов компьютерных программ.
Алан Купер (Alan Cooper), общепризнанный специалист в области обеспечения практичности программ, в своих работах подчеркивает важность образов использования. Он выделил две модели использования: переходную (transient) и независимую (sovereign). Приложения, соответствующие переходной модели, или переходное приложение, используются ежедневно, но обычно выполняют второстепенные функции. В отличие от него приложение, отвечающее независимой модели, или независимое приложение, в течение нескольких часов подряд завладевает всем вниманием пользователя.
Многие приложения по своей сути являются переходными или независимыми. Текстовый процессор, которым пользуется писатель, является независимым приложением. В его работу вовлечено большое количество переходных процедур, например средства управления файлами (обычно они встроены в текстовый процессор, а доступ к ним осуществляется посредством диалогового окна), словари или программа проверки орфографии (они также чаще всего встроены), а также почтовая программа, используемая для обмена сообщениями с коллегами. Для разработчика программного обеспечения текстовый редактор и отладчик, входящие в состав интегрированной системы разработки, являются независимыми программами. Независимые приложения обычно используются более интенсивно, чем переходные.
Как вы помните, хороший интерфейс должен быть незаметен для пользователя. Оценить качество работы можно следующим образом. Надо определить, насколько часто последовательность действий, направленных на решение задачи, прерывается из-за того, что пользователю приходится обращать внимание на интерфейс программы. Если при копировании файлов из одной папки в другую возникает задержка в одну-две секунды, пользователь будет чувствовать себя вполне комфортно. Если с такой же двухсекундной задержкой программа рисования будет отображать проведенные линии или отладчик будет выводить текущее значение переменной, пользователь обязательно начнет нервничать.
Web-узел Amazon представляет собой переходное приложение. К этому же типу относятся eBay, Google и большинство масштабных Webприложений. Когда всемирная сеть стала доступна широкой публике, некоторые предрекали, что вскоре традиционные офисные пакеты уступят место решениям на базе Web. С тех пор прошло больше десяти лет, но предсказание не сбылось. Web-страницы хороши как переходные приложения, но не как независимые.
46 Часть I. Новый взгляд на Web-приложение
Рис. 1.10. Эволюция велосипеда
К счастью, современные Web-браузеры так же напоминают первоначальную идею клиента для работы с удаленными документами, как швейцарский армейский ноле — каменный топор первобытного человека. Стремление улучшить программы просмотра информации из Web привели к созданию средств интерактивного взаимодействия, языков сценариев и встраиваемых модулей. (Получить представление о развитии Web можно, ознакомившись с документом www.webhistory.org/www.lists/www-talk.1993ql/0182.html. Сейчас же достаточно сказать, что в 1993 году Марку Андрессену пришлось убеждать Тима Бернерса-Ли и других специалистов в том, что язык HTML лишь выиграет, если ввести в него дескриптор для поддержки изображений.)
В течение нескольких лет лишь немногие отваживались признать JavaScript серьезным языком программирования. Большинство считали его лишь средством для отображения окон с сообщениями и создания интерактивных рекламных вставок.
Ajax можно рассматривать как "реабилитационный центр" для жертв "войны браузеров" — средств, в свое время не понятых и отвергнутых. Предоставив среду для работы, мы можем вернуть JavaScript статус "полноправного члена" Интернет, способного обеспечить практичность Web-приложений, не доставляя беспокойства пользователям и не требуя замены браузеров. Добиться этого нам помогут тщательно продуманные прбстые в использовании инструменты. В качестве примера таких инструментов можно привести образы разработки, которые мы часто используем в своей работе. Мы будем периодически ссылаться на них в тексте книги.
Процесс введения новой технологии — не только технический, но и социальный. Получив в свое распоряжение технологию, пользователи должны хорошо представлять, какие преимущества она может обеспечить, и применять ее как нечто давно знакомое. Так, например, первые велосипеды назывались "лошадь для денди". Их приводили в движение, отталкиваясь ногами от земли. По мере того как эти устройства становились доступными различным слоям населения, конструкция усовершенствовалась: появились педали, тормоза, цепная передача и надувные шины. С каждым нововведением велосипед все меньше напоминал лошадь (рис. 1.10).
Глава 1. Каким должен быть Web-интерфейс 47
/
Нечто похожее происходит сегодня в Web. Технологии, которые лежат в основе Ajax, дают возможность превратить Web-страницы во что-то совершенно новое. В результате первых попыток применения Ajax Web-страницы были изменены так, что их уместно сравнить с переходной моделью по пути от "лошади для денди" к современному велосипеду. Но чтобы понять потенциальные возможности Ajax, нам надо отказаться от некоторых принципов создания Web-страниц, а следовательно, и от правил, которым мы следовали в течение последних лет. Лишь несколько месяцев прошло с момента появления Ajax, а процесс преобразования Web уже начался.
1.2. Четыре основных принципа Ajax
Классическая модель приложения на основе Web-страниц связана не только с используемыми базовыми средствами, но и с нашим образом мышления. Потратим несколько минут на то, чтобы выявить основные предпосылки и определить, что надо делать, чтобы получить наибольшую выгоду от использования Ajax.
1.2.1. Браузер имеет дело с приложением, а не с содержимым
Для классического приложения на базе Web-страниц браузер представляет собой лишь низкоуровневый терминал. Он не имеет информации о том, какой этап работы выполняется пользователем. На сервере содержатся минимальные сведения об этом, которые, по сути, сводятся к поддержке сеанса. Если вы работаете с Java или .NET, средства поддержки сеанса на сервере доступны, подобно запросам ответам и MIME-типам, посредством стандартного API. На рис. 1.11 показан типичный жизненный цикл классического Web-приложения.
Когда пользователь регистрируется или другим способом инициализирует сеанс, создается несколько объектов на стороне сервера. Они представляют, например, "корзинку" покупателя или платежную карточку пользователя. Одновременно браузер получает исходную страницу. Она доставляется в виде потока HTML-данных, которые представляют собой сочетание стандартных элементов и данных, специфических для конкретного пользователя.
При каждом обращении к серверу браузер получает очередную страницу, содержащую данные тех же типов, что в предыдущих документах. Браузер исправно убирает с экрана старый документ и отображает новый. Других Действий от него и не следует ожидать: это низкоуровневая программа, которая делает только то, что было предусмотрено разработчиками.
Когда пользователь активизирует ссылку, соответствующую окончанию сеанса, или закрывает браузер, выполнение приложения завершается и сеанс разрушается. Информация, которую пользователь должен увидеть при следующей регистрации, заносится в долговременное хранилище. В Ajaxприложении часть прикладной логики переносится на браузер (рис. 1.12).
48 Часть I. Новый взгляд на Web-приложение
Рис. 1.11. Жизненный цикл классического Web-приложения. Сведения о текущем состоянии "диалога" пользователя с приложением хранятся на Web-сервере, пользователь же видит лишь последовательность страниц. Ни одна из них не обеспечивает продолжения диалога без обращения к серверу
После регистрации пользователя клиентское приложение доставляется браузеру. На многие действия пользователя это приложение способно реагировать самостоятельно. Если имеющихся в наличии возможностей недостает, оно передает запросы серверу, не прерывая последовательность действий пользователя.
При регистрации пользователя браузеру предоставляется более сложный документ, существенную часть которого составляет код JavaScript. Этот документ остается доступным пользователю в течение всего сеанса; при этом, в зависимости от действий пользователя, он изменяет свой внешний вид. Клиентская программа знает, как реагировать на вводимые данные, и способна решать, обрабатывать ли их самостоятельно, посылать ли запрос серверу (который в свою очередь обратится к базе данных или к другому ресурсу) или сделать и то и другое.
Глава 1. Каким должен быть Web-интерфейс 49
Рис. 1.12. Жизненный цикл Ajax-приложения
Поскольку документ присутствует на стороне клиента в течение всего сеанса, он способен хранить информацию о его состоянии. Например, сведения о состоянии "корзинки" покупателя могут храниться не на сервере, а в клиентской программе.
1.2.2. Сервер доставляет данные, а не содержимое
Как было сказано ранее, на каждом этапе работы классическое Webприложение предоставляет сочетание стандартных элементов и специальных данных. Когда пользователь добавляет товар в "корзинку", приложение в ответ должно лишь изменить общую цену либо, при наличии ошибки, сообщить о ней. Как видно на рис. 1.13, код, отвечающий за эти действия, составляет незначительную часть документа.
В Ajax-приложении "корзинка" может обладать более высоким "интеллектом" и передавать серверу асинхронные запросы. Шаблон, элементы навигации и другие компоненты страницы уже присутствуют на стороне клиента, поэтому сервер должен передавать только данные, полученные в результате обработки запроса.
50 Часть I. Новый взгляд на Web-приложение
(А)
(Б)
I
(В)
Рис. 1.13. Информация, доставляемая классическим Web-приложением
(а) и Ajax-приложением (б). С увеличением длительности работы (в) суммарный трафик классического Web-приложения возрастает быстрее, чем трафик Ajax-приложения
Глава 1. Каким должен быть Web-интерфейс 51
Ajax-приложение может достичь данной цели различными способами, например, вернуть фрагмент JavaScript-кода, поток, содержащий обычный текст или небольшой XML-документ. Преимущества и недостатки каждого из этих решений мы подробно обсудим в главе 5. Сейчас же достаточно заметить, что данные в любом из этих форматов будут иметь значительно меньший объем, чем страница, возвращаемая классическим Web-приложением.
График, представляющий возрастание трафика при работе Ajax-прило- жения, имеет крутой фронт, объясняемый тем, что при регистрации пользователя клиентской программе доставляется сложное приложение. Дальнейшее взаимодействие с сервером становится гораздо более эффективным. Для переходного приложения, созданного на базе Web-страниц, суммарный трафик может оказаться меньше, чем для Ajax-приложения. Однако по мере увеличения времени работы пользователя ситуация меняется и Ajaxприложение становится гораздо более экономичнее своего конкурента, выполненного в рамках классического подхода.
12.3.Пользователь может непрерывно взаимодействовать
сприложением
В Web-браузере предусмотрены два основных механизма ввода данных: гипертекстовые ссылки и HTML-формы.
Гипертекстовые ссылки могут быть сформированы на сервере и снабжены параметрами CGI (Common Gateway Interface — интерфейс общего шлюза). Их можно оформить как изображения и средствами CSS (Cascading Style Sheets — каскадные таблицы стилей) организовать обратную связь с пользователями, например, обеспечить изменение внешнего вида при наведении на них курсора мыши. Хороший Web-дизайнер при желании добьется того, что ссылки будут выглядеть как полноправные компоненты пользовательского интерфейса.
Формы могут содержать многие компоненты, типичные для пользовательского интерфейса обычных приложений, а именно: поля редактирования, флажки и переключатели опций, раскрывающиеся списки и пр. Однако некоторые из компонентов в составе форм не поддерживаются. Так, например, в формах не предусмотрены деревья и таблицы. Формы, как и гипертекстовые ссылки, содержат URL, указывающие на ресурсы сервера.
Гипертекстовые ссылки и формы могут также указывать на функции JavaScript. В традиционных Web-документах часто можно встретить JavaScript-сценарии, проверяющие корректность заполнения форм. Они следят за незаполненными полями, значениями, выходящими за пределы допустимого диапазона, и другими подобными ошибками. Передача данных на сервер происходит лишь в том случае, если форма заполнена корректно. JavaScript-функции присутствуют на стороне клиента в течение того же времени, что и содержащая их Web-страница.
При обращении к очередной странице пользователю приходится на время прервать работу. Предыдущий документ еще некоторое время отображается на экране; некоторые браузеры даже позволяют активизировать какую-либо
52 Часть I. Новый взгляд на Web-приложение
из видимых ссылок, но результаты предсказать невозможно. Скорее всего, пользователь, поступивший подобным образом, разрушит информацию о сеансе, поддерживаемую на сервере. После получения новой страницы пользователю предоставляются приблизительно те же возможности выбора, которые он имел до этого. Например, добавление в "корзинку" товара, скажем, брюк, вряд ли приведет к переходу от категории "мужская одежда" к категории "женская одежда" или "детская одежда".
Представим себе теперь, как ведет себя "корзинка" покупателя, реализованная в составе Ajax-приложения. Поскольку Ajax позволяет передавать данные в асинхронном режиме, пользователь может добавлять товар в "корзинку" с той же скоростью, с которой он щелкает мышью. Если клиентская часть приложения выполнена профессионально, она без труда справится с данной задачей, и пользователю не придется в своей работе учитывать специфику взаимодействия программы и сервера.
Очевидно, что реальной "корзинки" не существует; она выполнена в виде объекта поддержки сеанса на сервере. Однако пользователь, который делает покупки, не должен ничего знать об объекте сеанса. "Корзинка" — это понятие, позволяющее упрощенно представить выполняемые действия. Необходимость переходить от понятия "корзинка" к объектам, содержащимся в памяти компьютера, создает дискомфорт для пользователя. Необходимость ожидать обновления страницы принуждает вернуться из виртуального мира в реальный (рис. 1.14). Приложение, реализованное средствами Ajax, свободно от этого недостатка. Приобретать товары в сетевом магазине пользователям приходится лишь время от времени, однако в других областях деятельности, например, при решении сложных инженерных задач, поминутное прерывание работы, связанное с необходимостью ожидать появления очередной страницы, недопустимо.
Еще одно преимущество Ajax состоит в том, что данная технология позволяет обрабатывать более обширный набор событий, соответствующих действиям пользователя. Становится возможным реализовать перетаскивание объектов и другие сложные функции интерфейса, в результате чего Webприложение становится похожим на обычную прикладную программу, выполняемую на настольной системе. С точки зрения практичности эта свобода действий важна не потому, что она больше соответствует представлениям пользователя о виртуальном мире, а потому, что позволяет лучше сочетать взаимодействие с пользователем и запросы к серверу.
Для того чтобы обратиться к серверу в классическом Web-приложении, мы должны щелкнуть на гипертекстовой ссылке либо активизировать элемент формы, а затем ожидать результата. Это неизбежно отвлекает от основной работы. Если же обращение к серверу происходит в ответ на перемещение мыши, перетаскивание объекта или нажатие клавиши, сервер работает параллельно с пользователем. Сказанное выше иллюстрирует Google Suggest (http: //www. google. com/webhp?complete=l). В данном примере приложение реагирует на нажатие клавиш по мере того, как пользователь вводит информацию в поле. Клиент взаимодействует с сервером, извлекает и отображает наиболее вероятные завершения фраз. Исходной информацией при этом
Глава 1. Каким должен быть Web-интерфейс 53
Рис. 1.14. Прерывание последовательности действий пользователя для обработки событий. Пользователь работает с двумя типами объектов: один тип непосредственно относится к выполняемой работе, а другой связан с используемой вычислительной системой. Когда
пользователю приходится часто переключаться от одного типа к другому, это рассеивает его внимание, в результате производительность труда снижается
являются запросы, выполненные другими пользователями или поисковыми серверами. Упрощенный вариант подобной службы мы рассмотрим в главе 8.
1.2.4. Реальное кодирование требует порядка
В классических Web-приложениях для реализации дополнительных возможностей в документы часто включают фрагменты JavaScript-кода. Страничная модель не позволяет этим фрагментам присутствовать на стороне клиента дольше самой страницы, а это ограничивает их применимость. В результате JavaScript приобрел репутацию языка, пригодного лишь для поделок и не заслуживающего внимания серьезных разработчиков.
Создание кода для Ajax-приложений существенно отличается от того, к чему успели привыкнуть программисты. Код, доставляемый клиенту в начале работы с приложением, доступен до завершения сеанса, причем он не прерывает и не замедляет работу пользователя и не приводит к напрасному расходованию памяти. Если разработчик стремится выйти на рынок независимых приложений, то он должен учитывать, что его программа будет использоваться по нескольку часов подряд. Для этого нужен высокопроизводительный код, допускающий сопровождение. При его создании необходима Дисциплина программирования и понимание задачи, как и при написании серверных программ.
Объем кода, вероятно, будет большим, чем в случае классического Webприложения. В результате большее значение получает сама структура кода. Создание приложения уже становится не под силу одиночке — этим должен заниматься коллектив разработчиков. В процессе работы необходимо обеспечить выделение подзадач, учитывать дальнейшую поддержку, одним словом,