ОглавлениеОглавление i. НОВЫЙ ВЗГЛЯД НА web-ПРИЛОЖЕНИЕ 31...

Оглавление

I. НОВЫЙ ВЗГЛЯД НА WEB-ПРИЛОЖЕНИЕ 31

1. Каким должен быть Web-интерфейс 33

2. Знакомство с Ajax 63

3. Управление кодом Ajax 99

II. ОСНОВНЫЕ ПОДХОДЫ К РАЗРАБОТКЕ ПРИЛОЖЕНИЙ 145

4. Web-страница в роли приложения 147

5. Роль сервера в работе Ajax-приложения 135

III. СОЗДАНИЕ ПРОФЕССИОНАЛЬНЫХ AJAX-ПРИЛОЖЕНИЙ 235

6. Информация для пользователя 237

7. Безопасность Ajax-приложений 271

8. Производительность приложения 303

Оглавление

АJAХ В ПРИМЕРАХ 347

Динамические связанные комбинации 349

Oпережающий ввод 381

Yлучшенный Web-портал Ajax 439

'Живой" поиск с использованием XSLT 479

Создание приложений Ajax, не использующих сервер 515

ПРИЛОЖЕНИЯ 569

Инструменты для профессиональной работы с Ajax 571

JavaScript и объектно-ориентированное программирование 597

Библиотеки Ajax 625

Предметный указатель 639

Содержание

I. НОВЫЙ ВЗГЛЯД НА WEB-ПРИЛОЖЕНИЕ 31

1. Каким должен быть Web-интерфейс 33

1.1. Нужны ли богатые клиенты 341.1.1. Действия пользователя при работе с приложением 351.1.2. Накладные расходы при работе в сети 391.1.3. Асинхронное взаимодействие 421.1.4. Независимый и переходный образы использования 45

1.2. Четыре основных принципа Ajax 471.2.1. Браузер имеет дело с приложением, а не с содержимым 471.2.2. Сервер доставляет данные, а не содержимое 491.2.3. Пользователь может непрерывно взаимодействовать с приложением 511.2.4. Реальное кодирование требует порядка 53

1.3. Применение богатых клиентов Ajax 541.3.1. Системы, созданные с использованием Ajax 541.3.2. Google Maps 55

1.4. Альтернативные технологии 581.4.1. Macromedia Flash 581.4.2. Java Web Start 59

1.5. Резюме 59

1.6. Ресурсы 60

8 Содержание

2. Знакомство с Ajax 63

2.1. Основные элементы Ajax 64

2.2. JavaScript изучался не зря 66

2.3. Определение внешнего вида с помощью CSS 682.3.1. Селекторы CSS 682.3.2. Свойства стилей 702.3.3. Простой пример использования CSS 71

2.4. Организация просмотра с помощью DOM 762.4.1. Обработка DOM с помощью JavaScript 782.4.2. Поиск узла DOM 802.4.3. Создание узла DOM 812.4.4. Добавление стилей к документу 822.4.5. Свойство innerHTML 83

2.5. Асинхронная загрузка с использованием XML 842.5.1. Элементы IFrame 842.5.2. Объекты XmlDocument и XMLHttpRequest 862.5.3. Передача запроса серверу 892.5.4. Использование функции обратного вызова для контроля запроса 912.5.5. Жизненный цикл процедуры поддержки запроса 92

2.6. Отличия Ajax от классических технологий 95



3. Управление кодом Ajax 99

3.1. Порядок из хаоса 1003.1.1. Образы разработки 1013.1.2. Реструктуризация и Ajax 1023.1.3. Во всем надо знать меру 1023.1.4. Реструктуризация в действии 103

3.2. Варианты применения реструктуризации 1063.2.1. Несоответствие браузеров: образы разработки Facade и Adapter 1073.2.2. Управление обработчиками событий: образ разработки Observer 1103.2.3. Повторное использование обработчиков событий:

образ разработки Command 1133.2.4. Обеспечение единственной ссылки на ресурс:

образ разработки Singleton 116

3.3. "Модель-представление-контроллер" 120

3.4. Применение MVC для серверных программ 1223.4.1. Серверная программа Ajax, созданная

без применения образов разработки 1233.4.2. Реструктуризация модели 1263.4.3. Разделение содержимого и представления 129


3.5. Библиотеки независимых производителей 1323.5.1. Библиотеки, обеспечивающие работу с различными браузерами 1333.5.2. Компоненты и наборы компонентов 1373.5.3. Элементы, располагаемые на стороне сервера 140



II. ОСНОВНЫЕ ПОДХОДЫ К РАЗРАБОТКЕ ПРИЛОЖЕНИЙ 145

4. Web-страница в роли приложения 147

4.1. Разновидности архитектуры MVC 1484.1.1. Применение архитектуры MVC к программам различных уровней 1484.1.2. Применение архитектуры MVC к объектам,

присутствующим в среде браузера 149

4.2. Представление в составе Ajax-приложения 1514.2.1. Отделение логики от представления . 1524.2.2. Отделение представления от логики 157

4.3. Контроллер в составе Ajax-приложения 1614.3.1. Классические JavaScript-обработчики 1614.3.2. Модель обработки событий W3C 1644.3.3. Реализация гибкой модели событий в JavaScript 165

4.4. Модель в составе Ajax-приложения 1694.4.1. Использование JavaScript для моделирования предметной области 1704.4.2. Взаимодействие с сервером 171

4.5. Генерация представления на основе модели 1734.5.1. Отражение объектов JavaScript 1734.5.2. Обработка массивов и объектов 177

4.5.3. Включение контроллера . 180



5. Роль сервера в работе Ajax-приложения ' 185

5.1. Программы, выполняемые на сервере 1865.2. Создание программ на стороне сервера 187

5.2.1. Популярные языки программирования 1875.2.2. N-уровневые архитектуры 1885.2.3. Управление моделью предметной области на стороне клиента

и на стороне сервера 189

5.3. Принципы создания программ на сервере 1905.3.1. Серверные программы, не соответствующие основным

принципам разработки 1905.3.2. Использование архитектуры Model2 1925.3.3. Использование архитектуры на базе компонентов 1935.3.4. Архитектуры, ориентированные на использование Web-служб 196


5.4. Частные решения: обмен данными 2005.4.1. Взаимодействие, затрагивающее только клиентскую программу 2015.4.2. Пример отображения информации о планетах 2015.4.3. Взаимодействие, ориентированное на содержимое 2045.4.4. Взаимодействие, ориентированное на сценарий 2075.4.5. Взаимодействие, ориентированное на данные 212

5.5. Передача данных серверу 2175.5.1. Использование HTML-форм 2175.5.2. Использование-объекта XMLHttpRequest 2195.5.3. Управление обновлением модели 221



I. СОЗДАНИЕ ПРОФЕССИОНАЛЬНЫХ AJAX-ПРИЛОЖЕНИЙ 235

5. Информация для пользователя 237

6.1. Создание качественного приложения 2386.1.1. Отклик программы 2396.1.2. Надежность 2396.1.3. Согласованность 2406.1.4. Простота 2416.1.5. Как получить результат 241

6.2. Предоставление сведений пользователю 2426.2.1. Поддержка ответов на собственные запросы 2426.2.2. Обработка обновлений, выполненных другими пользователями 244

6.3. Создание системы оповещения 2486.3.1. Основные принципы оповещения 2496.3.2. Определение требований к пользовательскому интерфейсу 251

6.4. Реализация базовых средств оповещения 2526.4.1. Отображение пиктограмм в строке состояния 2526.4.2. Отображение подробных сообщений 2556.4.3. формирование готовой системы 256

6.5. Предоставление информации в запросах 262

6.6. Информация о новизне данных 2666.6.1. Простой способ выделения данных 2666.6.2. Выделение данных с использованием библиотеки Scriptaculous 268



Т. Безопасность Ajax-приложений 271

7.1. JavaScript и защита браузера 2727.1.1. Политика "сервера-источника" 2737.1.2. Особенности выполнения сценариев в Ajax-приложении 2737.1.3. Проблемы с поддоменами 2747.1.4. Несоответствие средств защиты в различных браузерах 275

Содержание 11

7.2. Взаимодействие с удаленным сервером 2767.2.1. Сервер в роли посредника при обращении к удаленной службе 2777.2.2. Взаимодействие с Web-службами 278

7.3. Защита конфиденциальной информации 2887.3.1. Вмешательство в процесс передачи данных 2887.3.2. Организация защищенного НТТР-взаимодействия 2897.3.3. Передача шифрованных данных в ходе обычного

НТТР-взаимодействия 2917.4. Управление доступом к потокам данных Ajax 293

7.4.1. Создание защищенных программ на уровне сервера 2937.4.2. Ограничение доступа к данным из Web 297



8. Производительность приложения зоз

8.1. Что такое производительность 3048.2. Скорость выполнения JavaScript-программ 305

8.2.1. Определение времени выполнения приложения 3068.2.2. Использование профилировщика Venkman 3108.2.3. Оптимизация скорости выполнения Ajax-приложения 313

8.3. Использование памяти JavaScript-кодом 3248.3.1. Борьба с утечкой памяти 3248.3.2. Особенности управления памятью в приложениях Ajax 327

8.4. Разработка с учетом производительности 3338.4.1. Измерение объема памяти, занимаемой приложением 3338.4.2. Простой пример управления памятью 3378.4.3. Как уменьшить объем используемой памяти в 150 раз 342



IV. AJAX В ПРИМЕРАХ 347

9. Динамические связанные комбинации 349

9.1. Сценарий двойной комбинации 3509.1.1. Недостатки клиентского решения 3509.1.2. Недостатки клиентского решения 3519.1.3. Решения, предлагаемые Ajax 352

9.2. Архитектура клиента 3539.2.1. Разработка формы 3539.2.2. Разработка взаимодействия клиент/сервер 355

9.3. Реализация сервера: VB.NET 3569.3.1. Определение формата XML-ответа 3579.3.2. Написание кода сервера 358

9.4. Представление результатов 360


9.4.1. Навигация в документе XML 3619.4.2. Применение каскадных таблиц стилей 362

9.5. Дополнительные вопросы 3649.5.1. Запросы при выборе нескольких элементов 3649.5.2. Переход от двойного связного выбора к тройному 365

9.6. Реструктуризация 3669.6.1. Новый и улучшенный объект net.ContentLoader 3679.6.2. Создание компонента двойного списка 372

9.7. Резюме . 379

0. О п е р е ж а ю щ и й ввод 381

10.1. Изучаем опережающий ввод 38210.1.1. Типичные элементы приложений опережающею ввода 38210.1.2. Google Suggest 38410.1.3. Ajax как средство опережающего ввода 385

10.2. Структура серверной части сценария: С# 38610.2.1. Сервер и база данных 38610.2.2. Тестирование серверного кода 388

10.3. Структура клиентской части сценария 38910.3.1.HTML 38910.3.2. JavaScript 39010.3.3. Обращение к серверу 400

10.4. Дополнительные возможности 410

10.5. Реструктуризация 41110.5.1. День 1: план разработки компонента TextSuggest 41210.5.2. День 2: создание TextSuggest— понятного

и настраиваемого компонента 41510.5.3. День 3: включаем Ajax 41810.5.4. День 4: обработка событий 42310.5.5. День 5: пользовательский интерфейс всплывающего окна

с предлагаемыми вариантами 43010.5.6. Итоги 437

10.6. Резюме 437

1. У л у ч ш е н н ы й Web-портал Ajax 439

11.1. Эволюционирующий портал 44011.1.1. Классический портал 44011.1.2. Портал с богатым пользовательским интерфейсом 442

11.2. Создание портала с использованием Java 443

11.3. Регистрация Ajax 44411.3.1. Таблица пользователя 44511.3.2. Серверная часть кода регистрации: Java 44611.3.3. Структура регистрации (клиентская часть) 449


11.4. Реализация окон DHTML 45411.4.1. База данных окон портала 45411.4.2. Серверный код окна портала 45511.4.3. Добавление внешней библиотеки JavaScript 460

11.5. Возможность автоматического сохранения 46211.5.1, Адаптация библиотеки 46311.5.2. Автоматическая запись информации в базе данных 465

11.6. Реструктуризация 46811.6.1. Определение конструктора 47011.6.2. Адаптация библиотеки AjaxWindows.js 47111.6.3. Задание команд портала 47311.6.4. Обработке средствами Ajax 47611.6.5. Выводы 477

11.7. Резюме 478

12. "Живой" поиск с использованием XSLT 479

12.1. Понимание технологий поиска 48012.1.1. Классический поиск 48012.1.2. Недостатки использования фреймов и всплывающих окон 48212.1.3. "Живой" поиск с использованием Ajax и XSLT 48312.1.4. Возврат результатов клиенту 484

12-2. Код клиентской части сценария 48512.2.1. Настройка клиента 48612.2.2. Инициализация процесса 487

12.3. Код серверной части приложения: РНР 48812.3.1. Создание XML-документа 48912.3.2. Создание документа XSLT 491

12.4. Объединение документов XSL и XML 49412.4.1. Совместимость с браузером Microsoft Internet Explorer 49612.4.2. Совместимость с браузерами Mozilla 496

12.5. Последние штрихи 49712.5.1. Применение каскадных таблиц стилей 49812.5.2. Улучшение поиска 49912.5.3. Использовать ли XSLT 50112.5.4. Решение проблемы закладок 502

12.6. Реструктуризация р

12.6.1. Объект XSLTHelper12.6.2. Компонент "живого" поиска12.6.3. Выводы

12.7. Резюме

13. Создание приложений Ajax, не использующ-

13.1. Считывание информации из внешнего мира13.1.1. Поиск XML-лент13.1.2. Изучение структуры RSS

14 Содержание

13.2. Богатый пользовательский интерфейс 52013.2.1. Чтение лент 52113.2.2. HTML-структура без таблиц 52213.2.3. Гибкое CSS-форматирование 525

13.3. Загрузка RSS-лент 53013.3.1. Глобальный уровень 53013.3.2. Предварительная загрузка средствами Ajax 532

13.4. Богатый эффект перехода 53513.4.1. Правила прозрачности, учитывающие индивидуальность браузеров 53613.4.2. Реализация затухающего перехода 53613.4.3. Интеграция таймеров JavaScript 538

13.5. Дополнительные возможности 54013.5.1. Введение дополнительных лент 54013.5.2. Интеграция функций пропуска и паузы 542

13.6. Как избежать ограничений проекта 54513.6.1. Обход системы безопасности браузеров Mozilla 54513.6.2. Изменение масштаба приложения 548

13.7. Реструктуризация 54813.7.1. Модель приложения 54913.7.2. Представление приложения 55113.7.3. Контроллер приложения 55513.7.4. Выводы 567

13.8. Резюме 567

У. ПРИЛОЖЕНИЯ 569

А. Инструменты для профессиональной работы с Ajax 571

А.1. Правильный набор инструментов 572А.1.1. Получение совместимых инструментов 572А.1.2. Создание собственных инструментов 574А.1.3. Сопровождение набора инструментов 574

А.2. Редакторы и IDE 575А.2.1. Что требуется от редактора кода 575А.2.2. Существующие продукты 577

А.З. Отладчики 582А.3.1. Для чего нужен отладчик 582А.З.2. Отладчики JavaScript 582А.3.3. Отладчики HTTP 587А.3.4. Создание консоли вывода, встроенной в браузер 589

А.4. Инспекторы DOM 592А.4.1. Использование DOM Inspector для браузеров Mozilla 592А.4.2. Инспекторы DOM для браузера Internet Explorer 594А.4.3. Средство Safari DOM Inspector для Mac OS X 594

A.5. Установка расширений Firefox 595

А.6. Ресурсы 597


В. JavaScript и объектно-ориентированное программирование 597

Б.1. JavaScript — это не Java 598Б.2. Объекты в JavaScript 599

Б.2.1. формирование объектов 600Б.2.2. функции-конструкторы, классы и прототипы 604Б.2.3. Расширение встроенных классов 606Б.2.4. Наследование прототипов 607Б.2.5. Отражение в JavaScript-объектах 608Б.2.6. Интерфейсы и виртуальные типы 610

Б.З. Методы и функции 613Б.3.1. функции как независимые элементы 613Б.3.2. Присоединение функций к объектам 615Б.3.3. Заимствование функций из других объектов 615Б.3.4. Обработка событий в Ajax-программах и контексты функций 616Б.3.5. Замыкания в JavaScript 620

Б.4. Выводы 623

Б.5, Ресурсы 623

В. Библиотеки Ajax 625

Предметный указатель 639

Введение

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

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

Со временем я перешел на более ответственную работу. Моей задачейбыло написание базовых средств для службы сообщений корпоративной си-стемы. При поступлении на работу было оговорено, что основным языкомбудет Java, но прошло немного времени, и незаметно моей главной задачейстала разработка пользовательских интерфейсов на JavaScript. Как ни стран-но, я все чаще стал слышать мнения специалистов о том, что JavaScript —достаточно серьезный язык и создание библиотек для него — перспективнаяработа. Вскоре мне пришлось ознакомиться с библиотекой х, разработаннойМайком Фостером (Mike Foster); о ней вы узнаете, прочитав данную книгу.Однажды при разборе почты мне пришла в голову идея принимать новыесообщения в скрытом фрейме и включать их в состав пользовательского ин-терфейса без обновления содержимого экрана. Несколько часов вдохновеннойработы — и в моих руках оказался действующий макет системы. Более то-го, я придумал выделять новые сообщения цветом, чтобы привлечь к нимвнимание пользователя. Придя в хорошее расположение духа от созданияинтересной игрушки, я вернулся к серьезной работе. Я не знал, что прибли-зительно в то же время Эрик Костелло (Eric Costello), Эрик Хетчер (ErikHatcher), Брент Эшли (Brent Ashley) и многие другие воплощали подобныеидеи, а в компании Microsoft шла работа над объектом XMLHttpRequest дляOutlook Web Access.

Судьба продолжала направлять меня по одному ей известному пути. Мояследующая работа была связана с разработкой программного обеспечения

Введение

щя крупного банка. Мы использовали Java и JavaScript и применили нафактике подход с использованием скрытых фреймов. Группа, которой я ру-юводил, поддерживала более 1,5 Мбайт JavaScript-кода, как расположенногоt статических документах, так и генерируемого JSP. Он используется при вы-юлнении банковских операций, суммы которых составляют миллионы долла-)ов. Среди читателей этой книги, быть может, есть те, счета которых управ-[яются данной программой.

Тем временем JavaScript продолжал развиваться. В феврале 2005 годаДжеймс Гаррет (James Garrett) нашел "недостающее звено". Он предложил:ороткое и запоминающееся имя Ajax для инфраструктуры, объединяющейогатых клиентов, которые взаимодействуют с серверами в асинхронном ре-жиме, и DHTML. Сочетание нескольких известных технологий создало усло-ия для программных решений, которые не были возможны ранее.

Инфраструктура Ajax привлекла к себе внимание многих специалистов;ыли созданы Prototype, Rico, Dojo, qooxdoo, Sarissa и многие другие библио-еки. Мы попытаемся кратко проанализировать их в приложении В. Работаяними, я получил массу удовольствия.

Ajax нельзя рассматривать как нечто завершенное. Данное направлениеродолжает развиваться. Через четыре месяца после написания первой главыастоящей книги мне пришлось существенно изменить ее. Несомненно, сле-ующие несколько лет порадуют нас новыми разработками в этой области.[ очень рад, что Эрик и Даррен разделили со мной труд и радость написаниягой книги.

Надеюсь, что вы, читатель, присоединитесь к нам в путешествии по увле-ательной стране, название которой — Ajax.

Дейв Крейн

Несколько слов о книге

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

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

Данная книга посвящена в основном созданию кода, выполняющегосяна стороне клиента, поэтому бльшая часть примеров написана на языкеJavaScript. Применение принципов Ajax позволяет разделить клиентскуюи серверную часть приложения, поэтому для написания программ, выпол-няющихся на стороне сервера, может использоваться любой язык. Таким об-разом, данная книга будет полезна разработчикам независимо от того, приме-няют ли они для серверных программ PHP, Java, C# или Visual Basic. Крометого, разрабатывая примеры, мы старались добиться относительной просто-ты серверного кода, поэтому вы можете без труда переносить их в требуемую

26 Несколько слов о книге

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

На кого рассчитана книга

В рамках Ajax объединено несколько дисциплин, поэтому читатели могутприйти к пониманию данной инфраструктуры различными путями. Частьпредполагаемой аудитории — это профессиональные разработчики корпора-тивных систем, имеющие ученые степени в области компьютерных наук, заплечами которых годы продуктивной работы над большими программнымипроектами. Их кругозор позволяет выйти за рамки уровня представленияклассического Web-приложения. Другую группу читателей составляют Web-дизайнеры, которые освоили "новую среду", изучив такие языки, как РНР,Visual Basic, JavaScript и ActionScript. Нельзя также забывать разработчи-ков приложений, перешедших от настольных систем к Web, и системных ад-министраторов, которых в основном интересуют инструментальные средствауправления на базе Web.

Все эти категории читателей объединяет неподдельный интерес к Ajax.При написании книги мы попытались в той или иной мере учесть интере-сы каждой из этих категорий. Для тех, кто рассматривает Web-браузер какнизкоуровневый терминал, мы предоставили информацию об основных тех-нологиях Web. Для тех, кто готов следовать сложившемуся стилю програм-мирования, мы предложили основные сведения о разработке и организациипрограммного кода. Чем бы вы ни занимались ранее, вы должны знать, чтоAjax — это объединение различных технологий и, изучая данную инфра-структуру, вам неизбежно придется столкнуться с новыми для себя вопроса-ми. Мы призываем вас расширить свой кругозор и повысить квалификацию.Мы сами делаем это постоянно; занимались этим мы и при написании даннойкниги. Затраченные усилия окупают себя, а результаты проявляются в раз-личных областях нашей профессиональной деятельности.

Структура книги

Книга разделена на четыре части. В части I вы узнаете, что такое Ajax и по-чему вам стоит взять эту инфраструктуру в свой арсенал средств и приемовразработки. Здесь же мы расскажем об инструментах, которые упростят ра-боту и повысят вероятность успеха. Часть II посвящена базовым технологи-ям, составляющим Ajax, а в части III вы узнаете, как перейти от формули-ровки основных понятий к созданию реального программного обеспечения.В части IV мы перейдем к конкретным примерам: поэтапно рассмотрим осо-бенности работы над пятью проектами Ajax. Затем мы реструктуризируемкод и выделим компоненты, которые вы сможете использовать в собственныхWeb-приложениях.

Еще раз подчеркнем, что Ajax — это не технология, а скорее процесс.Поэтому в главе 1 мы постарались рассказать разработчикам, привыкшимк традиционным подходам к созданию Web-программ, о том, что им при-

Несколько слов о книге 27

дется столкнуться с совершенно новой методологией написания приложе-ний. Мы рассмотрели основные различия между Ajax и классическими Web-приложениями, уделили внимание практичности программ и обсудили ряддругих понятий. Если вы хотите с самого начала составить общее представ-ление о том, что же такое Ajax, мы советуем вам начать с этой главы. Если жевы выступаете в роли "потребителя кода", вам стоит сразу перейти к главе 2.

Технологии, составляющие Ajax, давно известны, поэтому они хорошодокументированы. Краткий их обзор, сопровождаемый примерами, приведенв главе 2. Мы излагаем лишь общие сведения о данных технологиях и отнюдьне претендуем на полноту изложения. Мы лишь отмечаем особенности ихиспользования в рамках Ajax и специфику получаемых результатов.

Глава 3 посвящена одной из основных тем данной книги — управлениюкодом Ajax. Принимая во внимание тот фахт, что размер JavaScript-кода мо-жет превышать 1,5 Мбайт, трудно не согласиться с тем, что создание Ajax-приложения принципиально отличается от написания сценария для обычнойWeb-страницы. В этой главе мы обсудим образы разработки и реструктуриза-цию. Эти вопросы освещаются не столько потому, что они важны сами по се-бе, сколько потому, что они применяются при работе практически над любымприложением Ajax. Мы уверены, что вы также возьмете их на вооружение.

В главах 4 и 5 мы обратим ваше внимание на базовые компоненты Ajaxи на особенности практического применения некоторых образов разработки.В главе 4 речь пойдет о создании простого для восприятия клиентского ко-да. Основным инструментом будет выбрана известная архитектура "модель-представление-контроллер".

В главе 5 мы рассмотрим различные способы взаимодействия клиентаи сервера и их соответствие требованиям инфраструктуры Ajax. В результа-те вы получите полное представление о работе всех составных частей Ajax-приложения.

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

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


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

В часть IV входят главы 9-13. В них мы рассмотрим несколько проектовYjax. В каждом случае мы сначала обеспечим функционирование програм-.1Ы, а затем реструктуризируем ее так, чтобы вы могли включить ее элемен-:ы в свой проект, написав лишь несколько строк кода. Вы ознакомитесь нафактике с основными принципами реструктуризации и оцените преимуще-ства кода, пригодного для повторного использования.

В главе 9 мы обсудим способы расширения возможностей HTML-формсредствами Ajax. В частности, мы используем данные, введенные в поле, для5аполнения раскрывающегося списка. Чтобы это стало возможным, серверутередается асинхронный запрос.

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

В главе 11 речь снова пойдет о расширенных возможностях пользователь-ских интерфейсов Ajax. Мы разработаем портал, который, с точки зренияюльзователя, больше напоминает интерфейс рабочей станции, чем обычнуюvVeb-страницу. В частности, пользователю будут предоставлены окна, кото-зые можно не только перемещать, но и изменять их размеры. В асинхронномэежиме выполняются действия по поддержке перемещения окон, в результа-те, завершив сеанс взаимодействия и зарегистрировавшись с другой маши-1ы, вы увидите, что внешний вид интерфейса остался таким же, как в конце1редыдущего сеанса.

В главе 12 будет разработана поисковая система на базе Ajax, кото-рая демонстрирует возможности XSLT по преобразованию ХМL-информацииз форматированные данные.

В главе 13 мы представим Ajax-клиент без компонентов, выполняющих-:я в фоновом режиме. Он по-прежнему взаимодействует с программами настороне сервера, но в данном случае делает это непосредственно, используястандартный протокол RSS.

Заканчивается книга тремя приложениями, которые, как мы надеемся,принесут вам пользу. В основном тексте книги рассматривались лишь техно-логии. Разработчику, обратившемуся к инфраструктуре, подобной Ajax, го-раздо труднее подобрать подходящий набор инструментов, чем специалисту,использующему одну законченную технологию, например J2EE или .NET.Инструментальные средства Ajax еще не появились, но мы уверены, что про-изводители скоро предложат их. Пока это не случилось, при работе над про-ектами Ajax можно применять инструменты и программные решения, опи-сание которых мы приводим в приложении А.

Несколько слов о книге 29

Приложение Б ориентировано на разработчиков корпоративных систем,которые разбираются в программах и принципах их разработки, но не оченьуверенно чувствуют себя, применяя стандартные подходы при работе с гиб-ким и неструктурированным и, скажем прямо, странным языком JavaScript.Мы рассмотрим возможности языка и покажем, в чем состоят его основныеотличия от Java и С # .

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

Соглашения о представлении кода

Исходный код программ представлен моноширинным шрифтом. Это позволяетвыделить его на фоне обычного текста. При написании примеров для дан-ной книги применялись JavaScript, HTML, CSS, XML, Java, C # , Visual Basic.КЕТ и PHP, однако для всех языков используется одинаковый подход. Именаметодов и функций, свойства объектов, XML-элементы и атрибуты набраныодним и тем же шрифтом.

Во многих случаях мы изменяли формат исходного кода: добавляли пу-стые строки и отступы. В ряде случаев некоторые позиции кода пронумерова-ны. Это делалось для того, чтобы конкретизировать описание кода в тексте.

Коды примеров

Исходные коды примеров, приведенных в данной книге, можно скопировать,обратившись по адресу http://www.manning.com/crane. Их также можнонайти на сервере http://www.williamspublishing.com.

Создавая примеры, мы отдавали себе отчет в том, что далеко не у всех чи-тателей установлены сервер .NET, сервер приложений J2EE. Linux, Apache,MySQL, PHP/Python/Perl (LAMP), и в том, что большинство читателей ин-тересуются только клиентскими технологиями. Поэтому мы старались созда-вать примитивные варианты кода, которые могли бы работать с фиктивнымиданными, размещенными на сервере любого типа: Apache, Tomcat или IIS. На-ряду с упрощенными приводятся также реальные рабочие примеры, поэтомупри желании вы можете "померяться силами1' с базой данных или серверомприложений. Некоторые документы, содержащие сведения об установке ос-новных продуктов, предлагаются для копирования вместе с кодом.

http://www.manning.com/cranehttp://www.williamspublishing.com


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

Мы ждем ваших комментариев и надеемся на них. Вы можете прислатьнам бумажное или электронное письмо либо просто посетить наш Web-сервери оставить свои замечания там. Одним словом, любым удобным для вас спо-собом дайте нам знать, нравится или нет вам эта книга, а также выскажитесвое мнение о том. как сделать наши книги более интересными для вас.

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

E-mail: [email protected]: h t t p : //www.williamspublishing.com

Информация для писем:

из России: 115419, Москва, а/я 783• из Украины: 03150, Киев, а/я 152

mailto:[email protected]://www.williamspublishing.com

Часть I

Новый взгляд наWeb-приложение

В этой части описаны основные понятия, лежащие в основе Ajax, В гла-ве 1 рассказано о недостатках классических Web-приложений и новом под-ходе к их разработке. Глава 2 посвящена технологиям, составляющим Ajax,и взаимосвязи между ними. Эта информация поможет вам лучше усвоитьдальнейший материал и научиться писать приложения, более сложные, чемпривычная всем программа Hello, World. В главе 3 представлены инстру-менты разработки программ и управления проектами и рассказывается, какприменить их при работе над Ajax-приложениями.

Каким должен бытъWeb-интерфейс

В этой г л а в е . . .

• Асинхронное сетевое взаимодействиеи образы использования

• Основные различия между Ajax

и классическими Web-приложениями

• Основные принципы Ajax

• Ajax в реальном мире

Глава 1. Каким должен быть Web-интерфейс З5

Слово "богатый" означает обилие возможностей, заложенных в моделвзаимодействия. Эта модель предполагает поддержку разнообразных споссбов ввода данных и обеспечение своевременного и интуитивно понятного ответа. Выяснить, является ли взаимодействие богатым, можно лишь путе!сравнения интерфейсов. В качестве эталона можно выбрать некоторые хорешо зарекомендовавшие себя приложения для настольных систем, наприме]текстовые процессоры или электронные таблицы. Рассмотрим, что делаепользователь, работая с приложением.

1.1.1. Действия пользователя при работе с приложениемОторвитесь на минутку от книги, выберите любое приложение (только нWeb-браузер) и попытайтесь оценить, какие варианты взаимодействия с пользователем оно обеспечивает. Мы выбрали для этой цели электронные таблицы, но вы можете использовать другое приложение, например текстовьипроцессор.

Готово? Тогда давайте обсудим вновь приобретенный опыт. Попытавшие]ввести несколько простых формул, мы обнаружили, что сделать это можн<различными способами, например, редактировать текст в строке, активизировать пункты меню либо изменять данные, перетаскивая их с помощью мыши

В процессе работы осуществляется обратная связь, т.е. приложение обеспечивает отклик на действия пользователя. Вид курсора мыши изменяетсякнопки подсвечиваются, цвет выбранного текста изменяется, внешний вщактивизированных окон отличается от неактивных и т.д. (рис. 1.1). Именштакое поведение характерно для богатого взаимодействия. Так что же, программа поддержки электронных таблиц является богатым клиентом? Позволим себе не согласиться с этим утверждением.

В электронных таблицах и других подобных приложениях модель данных и логика их обработки функционируют в закрытой среде. Они могут бе:ограничений обращаться друг к другу, но внешний мир недоступен для них(рис. 1.2). Клиент же — это программа, которая взаимодействует с различными не зависящими один от другого процессами, выполняемыми обычно настороне сервера. Традиционно сервер — это более масштабное приложениечем клиент. Обычно он обеспечивает хранение больших объемов информациии управление ими. Клиент позволяет конечному пользователю просматриват!и модифицировать данные. Если с сервером одновременно взаимодействуютнесколько клиентов, он обеспечивает разделение данных. На рис. 1.3 условиепоказана архитектура клиент/сервер.

В современной n-связной архитектуре сервер взаимодействует с другимисерверными программами, которые ориентированы, например, на поддержкубазы данных или на выполнение специальных вычислений. Таким образомможно выделить средства промежуточного уровня, которые могут работатьи как клиент, и как сервер. Наши Ajax-приложения занимают в этой цепочкекрайнюю позицию, т.е. являются клиентами. Поэтому в ходе дальнейшегообсуждения мы будем рассматривать все остальные компоненты системы какединый "черный ящик", выполняющий функции сервера.

36 Часть I. Новый взгляд на Web-приложение

Рис. 1.1. Приложение, управляющее электронными таблицами, иллюстрирует различныеварианты взаимодействия с пользователем. Заголовки строк и столбцов подсвечиваются,внешний вид кнопки изменяется при помещении на нее курсора мыши, на панелиинструментов отображаются различные пиктограммы, а ячейки таблицы позволяютредактировать содержащиеся в них данные

Рис. 1.2. Архитектура приложения, предназначенного для выполнения в рамкахнастольной системы. Прикладная программа представляет собой отдельныйпроцесс, в пределах которого модель данных и логика их обработки могутвзаимодействовать друг с другом. Если на компьютере одновременно запущеныдва приложения, то ни одно из них не имеет доступа к модели данных другого.Взаимодействовать друг с другом они могут только посредством файловойсистемы. Обычно состояние программы определяется содержимым некоторогофайла. На время работы этот файл блокируется, не позволяя приложениямобмениваться информацией о состоянии

Глава 1. Каким должен быть Web-интерфейс 37

Рис. 1.3. Системы клиент/сервер в составе n-связной архитектуры. Сервер предоставляетразделяемую модель данных, с которой могут взаимодействовать клиенты. Для быстрого доступакаждый клиент поддерживает собственную частичную модель данных, которая синхронизированас моделью, находящейся на сервере. Модель на стороне клиента по сути является альтернативнымпредставлением бизнес-объектов. С сервером могут одновременно взаимодействовать несколькоклиентов, при этом осуществляется избирательная блокировка. На время работы сданными одногоклиента другим запрещается доступ к некоторым объектам или записям базы данных. Сервер можетбыть реализован как единый процесс (такой подход преимущественно применялся до середины1990-х годов) или включать несколько промежуточных уровней, поддерживать различныеWeb-службы и т.д. В любом случае с точки зрения клиента сервер предоставляет единую точку входаи может рассматриваться как "черный ящик"

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

Web-браузер несомненно является клиентом. Обращаясь к Web-серверу,браузер запрашивает у него тот или иной документ. Как правило, браузе-ры реализуют обширный набор функций, обеспечивающих просмотр Web-страниц. Например, пользователю доступны кнопка для возврата к преды-дущему документу, список предыстории и фреймы, позволяющие отобра-жать несколько документов. Однако мы считаем приложением набор стра-ниц, расположенных на конкретном Web-узле, поэтому универсальные сред-ства, предоставляемые браузером, связаны с приложением не больше, чемкнопка Star t (пуск) в системе Windows, посредством которой мы раскрыва-ем меню и запускаем программу поддержки электронных таблиц.

Рассмотрим современное Web-приложение. В качестве примера выбранузел Amazon (рис. 1.4), так как он знаком практически всем. Мы обратилиськ узлу Amazon посредством браузера. Поскольку сервер имеет информацию


Рис. 1.4. Исходная страница A m a z o n . com. Система имеет информацию о предыдущемвизите, поэтому для навигации предложены различные ссылки: как общие для всех, таки ориентированные на конкретного пользователя

о нашем прошлом визите, мы видим приветствие, список рекомендованныхкниг и сведения о предыдущих покупках.

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

Короче говоря, нам предоставлена разнообразная информация, элементыкоторой тесно связаны между собой. Чтобы получить доступ к этой инфор-мации, следует щелкать на гипертекстовых ссылках и заполнять формы. Ес-ли в процессе просмотра узла Amazon вы вздремнете за клавиатурой, то неузнаете, вышла ли новая книга о Гарри Поттере, до тех пор, пока не обновитеWeb-страницу в окне браузера. К сожалению, мы не можем перенести спи-сок рекомендованных книг с одной страницы на другую и изменить порядокследования текстовых фрагментов.

В этом нельзя обвинять специалистов Amazon, так как они проделалибольшую работу. Но по сравнению с электронными таблицами модель взаи-модействия, на которой основаны данные документы, безусловно ограничена.


Рис. 1.5. Подробная информация о книге, предоставляемая A m a z o n . com. На страницеимеются как универсальные ссылки, так и ссылки, предназначенные для конкретногопользователя. Здесь можно найти многие элементы, которые были показаны на рис. 1.4. Длятого чтобы пользователь мог с помощью Web-браузера выполнять необходимые операциис документом, эти элементы должны отображаться на каждой странице

Почему же подобные ограничения присущи всем современным Web-приложениям? Они обусловлены техническими причинами, которые мы сей-час рассмотрим.

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

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

•О Часть I. Новый взгляд на Web-приложение

Рис. 1.6. Диаграмма, иллюстрирующая вызов локальной процедуры. В процессе вызоваучаствует небольшое число элементов, поскольку модель данных и логика их обработкихранятся в локальной памяти и могут непосредственно взаимодействовать друг с другом

Рис. 1.7. Диаграмма, иллюстрирующая вызов удаленной процедуры. Программная логика наодном компьютере обращается к модели данных на другом компьютере

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


Запрос, который исходит от вызывающей функции, должен быть пред-ставлен в виде объекта, который затем подвергается сериализации (т.е. преоб-разуется в последовательный набор байтов). Сериализованные данные затемпередаются реализации протокола прикладного уровня (в современных усло-виях это чаще всего HTTP) и пересылаются по линиям связи (по проводам,оптоволоконным каналам или с помощью беспроводных соединений).

На удаленном компьютере данные, полученные посредством протоколаприкладного уровня, десериализуются, в результате чего формируется копияобъекта запроса. Этот объект передается модели данных, которая генерируетобъект ответа. Для передачи ответа вызывающей функции снова задейству-ются механизм сериализации и транспортные средства; в результате объектдоставляется вызывающей функции.

Процесс такого взаимодействия сложен, но его можно автоматизировать.Современные инструменты программирования, например Java или Microsoft.NET Framework, обеспечивают это. Тем не менее при удаленном вызове про-цедуры (RPC) реально выполняется большой объем вычислений, и если такиеобращения будут производиться слишком часто, производительность систе-мы снизится.

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

Но какое отношение это имеет к работе пользователя, которому предо-ставляется лишь интерфейс программы? Оказывается, очень большое.

Хороший интерфейс должен в чем-то имитировать реальный мир.А в большинстве случаев на действия в реальном мире следует немедленныйотклик. Даже небольшая задержка между действием и реакцией на него сби-вает с толку пользователя, отвлекает его от решаемой задачи и заставляетпереключить внимание на особенности самого интерфейса.

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

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


Рис. 1.8. Диаграмма, поясняющая синхронный ответ на действия пользователя.В качестве примера выбрана утренняя побудка детей. Время на диаграммеоткладывается по вертикальной оси. Серым цветом выделен период, в течениекоторого деятельность родителей приостанавливается

1.1.3. Асинхронное взаимодействиеРешить проблему задержки, связанной с передачей данных по сети, разра-ботчик может единственным образом — предположить наихудшее развитиесобытий. На практике это означает, что надо создавать пользовательскийинтерфейс так, чтобы он не зависел от сетевого взаимодействия. К счастью,в некоторых случаях проблемы, вызванные задержкой отклика, можно сде-лать менее острыми. Рассмотрим пример из реального мира. Всем родителямприходится отправлять по утрам детей в школу. Можно стать над ними и до-жидаться, пока они не встанут из постелей и не оденутся. На это уходитмного времени (рис. 1.8).

Необходимо будить детей, подавив желание выглянуть в окно и игнори-руя мяуканье кошки. Если дети попросили есть — это сигнал о том, что ониокончательно проснулись. Подобно процессу, выполняемому на сервере, детипробуждаются медленно. Если родитель будет следовать синхронной моделивзаимодействия, он затратит много времени на ожидание. Но в ожиданиизаветных слов "Все, мы проснулись, где завтрак?" можно заняться други-ми делами.


Возвращаясь к компьютерной тематике, сказанное означает выполнениедействий в асинхронном режиме. Для этой цели используется отдельный по-ток. Снова пользуясь примером из реального мира, можно сказать, что детибудут просыпаться сами "в своем потоке", а родителю не придется синхро-низировать с ними свои действия до тех пор, пока он не узнает, что детипроснулись (т.е. пока они на захотят завтракать). После этого родителю при-дется взаимодействовать с детьми, так как, получив уведомление, он узнает,что дети проснулись и оделись (рис. 1.9).

Любой достаточно квалифицированный разработчик пользовательскогоинтерфейса знает, что длительные вычисления лучше производить в отдель-ном потоке в фоновом режиме; в это время пользователь может выполнятьдругие действия. Конечно, на определенное время, необходимое для запускапотока, пользовательский интерфейс будет заблокирован, но это время оченьмало. Учитывая неизбежную задержку при сетевом взаимодействии, имеетсмысл априори считать любой вызов удаленной процедуры длительной опе-рацией и выполнять ее асинхронно.

Проблема четко сформулирована, и решение ее известно. Задержки, свя-занные с обменом по сети, играли роль в ранних приложениях клиент/сервер.Созданные неопытными разработчиками, клиенты "зависали" на неопреде-ленное время при попытке доступа к серверу, занимавшемуся обработкойбольшого числа запросов. Теперь, в эпоху Интернета, те же причины за-ставляют браузер временно останавливаться при переходе от одной Web-

Рис. 1.9. Диаграмма, иллюстрирующая асинхронный ответ на действияпользователя. Следуя асинхронной модели ввода, родитель, подав сигналпобудки, предоставляет детям просыпаться самостоятельно и оповестить егооб окончании этого процесса. В это время он продолжает заниматься другимиделами; при этом время, непосредственно потраченное на побудку детей,существенно сокращается


страницы к другой. Мы не можем влиять на задержку, связанную с взаи-модействием по сети, но можем минимизировать ее влияние, обращаясь кудаленным методам в асинхронном режиме.

К несчастью, нам, разработчикам Web-приложений, не так-то просто сле-довать этим давно известным рекомендациям. Протокол HTTP действует попринципу "запрос-ответ". Клиент передает запрос на получение документа,а сервер отвечает, либо предоставляя требуемые данные, либо информируяо том, что он не может их найти, либо предлагая перейти по другому адресу,либо сообщая клиенту, что тот может использовать копию, содержащуюсяв кэше. Протокол, в котором предусмотрено лишь взаимодействие "запрос-ответ", является в некотором смысле "односторонним". Клиент может обра-титься к серверу, но сервер по своей инициативе не может установить взаи-модействие с клиентом. Более того, в промежутке между двумя последова-тельными запросами сервер даже не имеет сведений о клиенте.

Большинство разработчиков Web-приложений используют современныетехнологии, такие как Java, PHP или .NET, поскольку в них поддерживаетсясеанс взаимодействия. Мысль о том, что неплохо бы реализовать в серверахподдержку текущего состояния процесса взаимодействия с клиентами, при-шла слишком поздно. Протокол HTTP очень хорошо выполняет те задачи,для которых он был изначально разработан, но адаптировать его для ре-шения вопросов, которые не были предусмотрены создателями данного про-токо�

ОглавлениеОглавление i. НОВЫЙ ВЗГЛЯД НА web-ПРИЛОЖЕНИЕ 31...

Documents