WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     || 2 | 3 | 4 | 5 |   ...   | 11 |
-- [ Страница 1 ] --

Оглавление 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. Нужны ли богатые клиенты 34 1.1.1. Действия пользователя при работе с приложением 1.1.2. Накладные расходы при работе в сети 1.1.3. Асинхронное взаимодействие 1.1.4. Независимый и переходный образы использования 1.2. Четыре основных принципа Ajax 1.2.1. Браузер имеет дело с приложением, а не с содержимым 1.2.2. Сервер доставляет данные, а не содержимое 1.2.3. Пользователь может непрерывно взаимодействовать с приложением 1.2.4. Реальное кодирование требует порядка 1.3. Применение богатых клиентов Ajax 1.3.1. Системы, созданные с использованием Ajax 1.3.2. Google Maps 1.4. Альтернативные технологии 1.4.1. Macromedia Flash 1.4.2. Java Web Start 1.5. Резюме 1.6. Ресурсы 8 Содержание 2. Знакомство с Ajax 2.1. Основные элементы Ajax 2.2. JavaScript изучался не зря 2.3. Определение внешнего вида с помощью CSS 2.3.1. Селекторы CSS 2.3.2. Свойства стилей 2.3.3. Простой пример использования CSS 2.4. Организация просмотра с помощью DOM 2.4.1. Обработка DOM с помощью JavaScript 2.4.2. Поиск узла DOM 2.4.3. Создание узла DOM 2.4.4. Добавление стилей к документу 2.4.5. Свойство innerHTML 2.5. Асинхронная загрузка с использованием XML 2.5.1. Элементы IFrame 2.5.2. Объекты XmlDocument и XML 2.5.3. Передача запроса серверу 2.5.4. Использование функции обратного вызова для контроля запроса 2.5.5. Жизненный цикл процедуры поддержки запроса 2.6. Отличия Ajax от классических технологий 2.7. Резюме 2.8. Ресурсы 3. Управление кодом Ajax 3.1. Порядок из хаоса 3.1.1. Образы разработки 3.1.2. Реструктуризация и Ajax 3.1.3. Во всем надо знать меру 3.1.4. Реструктуризация в действии 3.2. Варианты применения реструктуризации 3.2.1. Несоответствие браузеров: образы разработки Facade и Adapter 3.2.2. Управление обработчиками событий: образ разработки Observer 3.2.3. Повторное использование обработчиков событий:

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

образ разработки Singleton 3.3. "Модель-представление-контроллер" 3.4. Применение MVC для серверных программ 3.4.1. Серверная программа Ajax, созданная без применения образов разработки 3.4.2. Реструктуризация модели 3.4.3. Разделение содержимого и представления Содержание 3.5. Библиотеки независимых производителей 3.5.1. Библиотеки, обеспечивающие работу с различными браузерами 3.5.2. Компоненты и наборы компонентов 3.5.3. Элементы, располагаемые на стороне сервера 3.6. Резюме 3.7. Ресурсы II. ОСНОВНЫЕ ПОДХОДЫ К РАЗРАБОТКЕ ПРИЛОЖЕНИЙ 4. Web-страница в роли приложения 4.1. Разновидности архитектуры MVC 4.1.1. Применение архитектуры MVC к программам различных уровней 4.1.2. Применение архитектуры MVC к объектам, присутствующим в среде браузера 4.2. Представление в составе Ajax-приложения 4.2.1. Отделение логики от представления. 4.2.2. Отделение представления от логики 4.3. Контроллер в составе Ajax-приложения 4.3.1. Классические JavaScript-обработчики 4.3.2. Модель обработки событий W3C 4.3.3. Реализация гибкой модели событий в JavaScript 4.4. Модель в составе Ajax-приложения 4.4.1. Использование JavaScript для моделирования предметной области 4.4.2. Взаимодействие с сервером 4.5. Генерация представления на основе модели 4.5.1. Отражение объектов JavaScript 4.5.2. Обработка массивов и объектов 4.5.3. Включение контроллера. 4.6. Резюме 4.7. Ресурсы 5. Роль сервера в работе Ajax-приложения ' 5.1. Программы, выполняемые на сервере 5.2. Создание программ на стороне сервера 5.2.1. Популярные языки программирования 5.2.2. N-уровневые архитектуры 5.2.3. Управление моделью предметной области на стороне клиента и на стороне сервера 5.3. Принципы создания программ на сервере 5.3.1. Серверные программы, не соответствующие основным принципам разработки 5.3.2. Использование архитектуры Model2 5.3.3. Использование архитектуры на базе компонентов 5.3.4. Архитектуры, ориентированные на использование Web-служб Содержание 5.4. Частные решения: обмен данными 5.4.1. Взаимодействие, затрагивающее только клиентскую программу 5.4.2. Пример отображения информации о планетах 5.4.3. Взаимодействие, ориентированное на содержимое 5.4.4. Взаимодействие, ориентированное на сценарий 5.4.5. Взаимодействие, ориентированное на данные 5.5. Передача данных серверу 5.5.1. Использование HTML-форм 5.5.2. Использование-объекта XMLHttpRequest 5.5.3. Управление обновлением модели 5.6. Резюме 5.7. Ресурсы I. СОЗДАНИЕ ПРОФЕССИОНАЛЬНЫХ AJAX-ПРИЛОЖЕНИЙ 5. Информация для пользователя 6.1. Создание качественного приложения 6.1.1. Отклик программы 6.1.2. Надежность 6.1.3. Согласованность 6.1.4. Простота 6.1.5. Как получить результат 6.2. Предоставление сведений пользователю 6.2.1. Поддержка ответов на собственные запросы 6.2.2. Обработка обновлений, выполненных другими пользователями 6.3. Создание системы оповещения 6.3.1. Основные принципы оповещения 6.3.2. Определение требований к пользовательскому интерфейсу 6.4. Реализация базовых средств оповещения 6.4.1. Отображение пиктограмм в строке состояния 6.4.2. Отображение подробных сообщений 6.4.3. формирование готовой системы 6.5. Предоставление информации в запросах 6.6. Информация о новизне данных 6.6.1. Простой способ выделения данных 6.6.2. Выделение данных с использованием библиотеки Scriptaculous 6.7. Резюме 6.8. Ресурсы Т. Безопасность Ajax-приложений 7.1. JavaScript и защита браузера 7.1.1. Политика "сервера-источника" 7.1.2. Особенности выполнения сценариев в Ajax-приложении 7.1.3. Проблемы с поддоменами 7.1.4. Несоответствие средств защиты в различных браузерах Содержание 7.2. Взаимодействие с удаленным сервером 7.2.1. Сервер в роли посредника при обращении к удаленной службе 7.2.2. Взаимодействие с Web-службами 7.3. Защита конфиденциальной информации 7.3.1. Вмешательство в процесс передачи данных 7.3.2. Организация защищенного НТТР-взаимодействия 7.3.3. Передача шифрованных данных в ходе обычного НТТР-взаимодействия 7.4. Управление доступом к потокам данных Ajax 7.4.1. Создание защищенных программ на уровне сервера 7.4.2. Ограничение доступа к данным из Web 7.5. Резюме 7.6. Ресурсы 8. Производительность приложения зоз 8.1. Что такое производительность 8.2. Скорость выполнения JavaScript-программ 8.2.1. Определение времени выполнения приложения 8.2.2. Использование профилировщика Venkman 8.2.3. Оптимизация скорости выполнения Ajax-приложения 8.3. Использование памяти JavaScript-кодом 8.3.1. Борьба с утечкой памяти 8.3.2. Особенности управления памятью в приложениях Ajax 8.4. Разработка с учетом производительности 8.4.1. Измерение объема памяти, занимаемой приложением 8.4.2. Простой пример управления памятью 8.4.3. Как уменьшить объем используемой памяти в 150 раз 8.5. Резюме 8.6. Ресурсы IV. AJAX В ПРИМЕРАХ 9. Динамические связанные комбинации 9.1. Сценарий двойной комбинации 9.1.1. Недостатки клиентского решения 9.1.2. Недостатки клиентского решения 9.1.3. Решения, предлагаемые Ajax 9.2. Архитектура клиента 9.2.1. Разработка формы 9.2.2. Разработка взаимодействия клиент/сервер 9.3. Реализация сервера: VB.NET 9.3.1. Определение формата XML-ответа 9.3.2. Написание кода сервера 9.4. Представление результатов Содержание 9.4.1. Навигация в документе XML 9.4.2. Применение каскадных таблиц стилей 9.5. Дополнительные вопросы 9.5.1. Запросы при выборе нескольких элементов 9.5.2. Переход от двойного связного выбора к тройному 9.6. Реструктуризация 9.6.1. Новый и улучшенный объект net.ContentLoader 9.6.2. Создание компонента двойного списка 9.7. Резюме. 0. Опережающий ввод 10.1. Изучаем опережающий ввод 10.1.1. Типичные элементы приложений опережающею ввода 10.1.2. Google Suggest 10.1.3. Ajax как средство опережающего ввода 10.2. Структура серверной части сценария: С# 10.2.1. Сервер и база данных 10.2.2. Тестирование серверного кода 10.3. Структура клиентской части сценария 10.3.1.HTML 10.3.2. JavaScript 10.3.3. Обращение к серверу 10.4. Дополнительные возможности 10.5. Реструктуризация 10.5.1. День 1: план разработки компонента TextSuggest 10.5.2. День 2: создание TextSuggest— понятного и настраиваемого компонента 10.5.3. День 3: включаем Ajax 10.5.4. День 4: обработка событий 10.5.5. День 5: пользовательский интерфейс всплывающего окна с предлагаемыми вариантами 10.5.6. Итоги 10.6. Резюме 1. Улучшенный Web-портал Ajax 11.1. Эволюционирующий портал 11.1.1. Классический портал 11.1.2. Портал с богатым пользовательским интерфейсом 11.2. Создание портала с использованием Java 11.3. Регистрация Ajax 11.3.1. Таблица пользователя 11.3.2. Серверная часть кода регистрации: Java 11.3.3. Структура регистрации (клиентская часть) Содержание 11.4. Реализация окон DHTML 11.4.1. База данных окон портала 11.4.2. Серверный код окна портала 11.4.3. Добавление внешней библиотеки JavaScript 11.5. Возможность автоматического сохранения 11.5.1, Адаптация библиотеки 11.5.2. Автоматическая запись информации в базе данных 11.6. Реструктуризация 11.6.1. Определение конструктора 11.6.2. Адаптация библиотеки AjaxWindows.js 11.6.3. Задание команд портала 11.6.4. Обработке средствами Ajax 11.6.5. Выводы 11.7. Резюме 12. "Живой" поиск с использованием XSLT 12.1. Понимание технологий поиска 12.1.1. Классический поиск 12.1.2. Недостатки использования фреймов и всплывающих окон 12.1.3. "Живой" поиск с использованием Ajax и XSLT 12.1.4. Возврат результатов клиенту 12-2. Код клиентской части сценария 12.2.1. Настройка клиента 12.2.2. Инициализация процесса 12.3. Код серверной части приложения: РНР 12.3.1. Создание XML-документа 12.3.2. Создание документа XSLT 12.4. Объединение документов XSL и XML 12.4.1. Совместимость с браузером Microsoft Internet Explorer 12.4.2. Совместимость с браузерами Mozilla 12.5. Последние штрихи 12.5.1. Применение каскадных таблиц стилей 12.5.2. Улучшение поиска 12.5.3. Использовать ли XSLT 12.5.4. Решение проблемы закладок р 12.6. Реструктуризация 12.6.1. Объект XSLTHelper 12.6.2. Компонент "живого" поиска 12.6.3. Выводы 12.7. Резюме 13. Создание приложений Ajax, не использующ 13.1. Считывание информации из внешнего мира 13.1.1. Поиск XML-лент 13.1.2. Изучение структуры RSS 14 Содержание 13.2. Богатый пользовательский интерфейс 13.2.1. Чтение лент 13.2.2. HTML-структура без таблиц 13.2.3. Гибкое CSS-форматирование 13.3. Загрузка RSS-лент 13.3.1. Глобальный уровень 13.3.2. Предварительная загрузка средствами Ajax 13.4. Богатый эффект перехода 13.4.1. Правила прозрачности, учитывающие индивидуальность браузеров 13.4.2. Реализация затухающего перехода 13.4.3. Интеграция таймеров JavaScript 13.5. Дополнительные возможности 13.5.1. Введение дополнительных лент 13.5.2. Интеграция функций пропуска и паузы 13.6. Как избежать ограничений проекта 13.6.1. Обход системы безопасности браузеров Mozilla 13.6.2. Изменение масштаба приложения 13.7. Реструктуризация 13.7.1. Модель приложения 13.7.2. Представление приложения 13.7.3. Контроллер приложения 13.7.4. Выводы 13.8. Резюме У. ПРИЛОЖЕНИЯ А. Инструменты для профессиональной работы с Ajax А.1. Правильный набор инструментов А.1.1. Получение совместимых инструментов А.1.2. Создание собственных инструментов А.1.3. Сопровождение набора инструментов А.2. Редакторы и IDE А.2.1. Что требуется от редактора кода А.2.2. Существующие продукты А.З. Отладчики А.3.1. Для чего нужен отладчик А.З.2. Отладчики JavaScript А.3.3. Отладчики HTTP А.3.4. Создание консоли вывода, встроенной в браузер А.4. Инспекторы DOM А.4.1. Использование DOM Inspector для браузеров Mozilla А.4.2. Инспекторы DOM для браузера Internet Explorer А.4.3. Средство Safari DOM Inspector для Mac OS X A.5. Установка расширений Firefox А.6. Ресурсы Содержание В. JavaScript и объектно-ориентированное программирование Б.1. JavaScript — это не Java Б.2. Объекты в JavaScript Б.2.1. формирование объектов Б.2.2. функции-конструкторы, классы и прототипы Б.2.3. Расширение встроенных классов Б.2.4. Наследование прототипов Б.2.5. Отражение в JavaScript-объектах Б.2.6. Интерфейсы и виртуальные типы Б.З. Методы и функции Б.3.1. функции как независимые элементы Б.3.2. Присоединение функций к объектам Б.3.3. Заимствование функций из других объектов Б.3.4. Обработка событий в Ajax-программах и контексты функций Б.3.5. Замыкания в JavaScript Б.4. Выводы Б.5, Ресурсы В. Библиотеки Ajax Предметный указатель Введение Случается, что проходит много лет, прежде чем человек поймет свое пред назначение. Среди технологий, с которыми мне пришлось работать в начале 1990-х, был неприметный язык сценариев под названием JavaScript. Вскоре я понял, что, несмотря на название, он не имеет ничего общего с языком Java, с которым я предпочитал работать в то время. Однако судьба снова и снова сводила меня с JavaScript.

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

Со временем я перешел на более ответственную работу. Моей задачей было написание базовых средств для службы сообщений корпоративной си стемы. При поступлении на работу было оговорено, что основным языком будет Java, но прошло немного времени, и незаметно моей главной задачей стала разработка пользовательских интерфейсов на JavaScript. Как ни стран но, я все чаще стал слышать мнения специалистов о том, что JavaScript — достаточно серьезный язык и создание библиотек для него — перспективная работа. Вскоре мне пришлось ознакомиться с библиотекой х, разработанной Майком Фостером (Mike Foster);

о ней вы узнаете, прочитав данную книгу.

Однажды при разборе почты мне пришла в голову идея принимать новые сообщения в скрытом фрейме и включать их в состав пользовательского ин терфейса без обновления содержимого экрана. Несколько часов вдохновенной работы — и в моих руках оказался действующий макет системы. Более то го, я придумал выделять новые сообщения цветом, чтобы привлечь к ним внимание пользователя. Придя в хорошее расположение духа от создания интересной игрушки, я вернулся к серьезной работе. Я не знал, что прибли зительно в то же время Эрик Костелло (Eric Costello), Эрик Хетчер (Erik Hatcher), Брент Эшли (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-программ, о том, что им при Несколько слов о книге дется столкнуться с совершенно новой методологией написания приложе ний. Мы рассмотрели основные различия между 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 служб от несанкционированного обращения. В серьезных приложениях во просы безопасности крайне важны, и мы предпримем основные меры для контроля над ними.

28 Несколько слов о книге В главе 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 можно применять инструменты и программные решения, опи сание которых мы приводим в приложении А.

Несколько слов о книге Приложение Б ориентировано на разработчиков корпоративных систем, которые разбираются в программах и принципах их разработки, но не очень уверенно чувствуют себя, применяя стандартные подходы при работе с гиб ким и неструктурированным и, скажем прямо, странным языком 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' с базой данных или сервером приложений. Некоторые документы, содержащие сведения об установке ос новных продуктов, предлагаются для копирования вместе с кодом.

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

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

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

E-mail: info@williamspublishing.com WWW: http: //www.williamspublishing.com Информация для писем:

из России: 115419, Москва, а/я • из Украины: 03150, Киев, а/я Часть I Новый взгляд на Web-приложение В этой части описаны основные понятия, лежащие в основе Ajax, В гла ве 1 рассказано о недостатках классических Web-приложений и новом под ходе к их разработке. Глава 2 посвящена технологиям, составляющим Ajax, и взаимосвязи между ними. Эта информация поможет вам лучше усвоить дальнейший материал и научиться писать приложения, более сложные, чем привычная всем программа Hello, World. В главе 3 представлены инстру менты разработки программ и управления проектами и рассказывается, как применить их при работе над Ajax-приложениями.

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

• Асинхронное сетевое взаимодействие и образы использования • Основные различия между Ajax и классическими Web-приложениями • Основные принципы Ajax • Ajax в реальном мире Глава 1. Каким должен быть Web-интерфейс З Слово "богатый" означает обилие возможностей, заложенных в модел взаимодействия. Эта модель предполагает поддержку разнообразных спосс бов ввода данных и обеспечение своевременного и интуитивно понятного от вета. Выяснить, является ли взаимодействие богатым, можно лишь путе!

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

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

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

В электронных таблицах и других подобных приложениях модель дан ных и логика их обработки функционируют в закрытой среде. Они могут бе:

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

и модифицировать данные. Если с сервером одновременно взаимодействуют несколько клиентов, он обеспечивает разделение данных. На рис. 1.3 условие показана архитектура клиент/сервер.

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

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

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

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

Рассмотрим современное Web-приложение. В качестве примера выбран узел Amazon (рис. 1.4), так как он знаком практически всем. Мы обратились к узлу Amazon посредством браузера. Поскольку сервер имеет информацию 38 Часть I. Новый взгляд на Web-приложение Рис. 1.4. Исходная страница Amazon. com. Система имеет информацию о предыдущем визите, поэтому для навигации предложены различные ссылки: как общие для всех, так и ориентированные на конкретного пользователя о нашем прошлом визите, мы видим приветствие, список рекомендованных книг и сведения о предыдущих покупках.

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

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

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

Глава 1. Каким должен быть Web-интерфейс Рис. 1.5. Подробная информация о книге, предоставляемая Amazon. com. На странице имеются как универсальные ссылки, так и ссылки, предназначенные для конкретного пользователя. Здесь можно найти многие элементы, которые были показаны на рис. 1.4. Для того чтобы пользователь мог с помощью Web-браузера выполнять необходимые операции с документом, эти элементы должны отображаться на каждой странице Почему же подобные ограничения присущи всем современным Web приложениям? Они обусловлены техническими причинами, которые мы сей час рассмотрим.

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

Однако вызов удаленных и локальных процедур — это не одно и то же.

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

•О Часть I. Новый взгляд на Web-приложение Рис. 1.6. Диаграмма, иллюстрирующая вызов локальной процедуры. В процессе вызова участвует небольшое число элементов, поскольку модель данных и логика их обработки хранятся в локальной памяти и могут непосредственно взаимодействовать друг с другом Рис. 1.7. Диаграмма, иллюстрирующая вызов удаленной процедуры. Программная логика на одном компьютере обращается к модели данных на другом компьютере При работе в сети на обоих концах соединения выполняется большой бъем работы, скрытой от пользователя (рис. 1.7). Порой эти вычисления амедляют работу программы даже больше, чем пересылка данных по лини м связи. Процесс сетевого взаимодействия включает в себя решение самых азнообразных задач: передачу электрических сигналов по проводам (или пе есылку радиосигналов через спутник), представление этих сигналов в виде.воичных данных, проверку на наличие ошибок и организацию повторной ередачи, восстановление битовой последовательности и, наконец, интерпре ацию двоичной информации.

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

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

в результате объект доставляется вызывающей функции.

Процесс такого взаимодействия сложен, но его можно автоматизировать.

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

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

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

Хороший интерфейс должен в чем-то имитировать реальный мир.

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

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

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

42 Часть I. Новый взгляд на Web-приложение Рис. 1.8. Диаграмма, поясняющая синхронный ответ на действия пользователя.

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

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

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

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

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

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

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

Созданные неопытными разработчиками, клиенты "зависали" на неопреде ленное время при попытке доступа к серверу, занимавшемуся обработкой большого числа запросов. Теперь, в эпоху Интернета, те же причины за ставляют браузер временно останавливаться при переходе от одной Web 44 Часть 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-интерфейс / 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-интерфейс / Нечто похожее происходит сегодня в 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-интерфейс Рис. 1.12. Жизненный цикл Ajax-приложения Поскольку документ присутствует на стороне клиента в течение всего се анса, он способен хранить информацию о его состоянии. Например, сведения о состоянии "корзинки" покупателя могут храниться не на сервере, а в кли ентской программе.

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

В Ajax-приложении "корзинка" может обладать более высоким "интеллек том" и передавать серверу асинхронные запросы. Шаблон, элементы навига ции и другие компоненты страницы уже присутствуют на стороне клиента, поэтому сервер должен передавать только данные, полученные в результате обработки запроса.

50 Часть I. Новый взгляд на Web-приложение (А) (Б) I (В) Рис. 1.13. Информация, доставляемая классическим Web-приложением (а) и Ajax-приложением (б). С увеличением длительности работы (в) суммарный трафик классического Web-приложения возрастает быстрее, чем трафик Ajax-приложения Глава 1. Каким должен быть Web-интерфейс 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-интерфейс Рис. 1.14. Прерывание последовательности действий пользователя для обработки событий.

Пользователь работает с двумя типами объектов: один тип непосредственно относится к выполняемой работе, а другой связан с используемой вычислительной системой. Когда пользователю приходится часто переключаться от одного типа к другому, это рассеивает его внимание, в результате производительность труда снижается являются запросы, выполненные другими пользователями или поисковыми серверами. Упрощенный вариант подобной службы мы рассмотрим в главе 8.

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

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

Объем кода, вероятно, будет большим, чем в случае классического Web приложения. В результате большее значение получает сама структура кода.

Создание приложения уже становится не под силу одиночке — этим должен заниматься коллектив разработчиков. В процессе работы необходимо обеспе чить выделение подзадач, учитывать дальнейшую поддержку, одним словом, 54 Часть I. Новый взгляд на Web-приложение работа будет происходить по тому же сценарию, что и создание обычных про грамм для настольных систем.

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

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

1.3.1. Системы, созданные с использованием Ajax Наибольший вклад в формирование современного представления об Ajax приложениях внесла компания Google. (Она использовала данную техноло гию еще до того, как та получила имя Ajax.) Бета-версия службы GMail стала доступна в начале 2004 года. Эта служба привлекла внимание пользователей не только размерами предоставляемого им почтового ящика, но и интерфей сом, который позволял одновременно открывать несколько сообщений и авто матически обновлял список корреспонденции, даже если пользователь подго тавливал в это время новое сообщение. Это был существенный шаг вперед по сравнению с обычными почтовыми системами, предлагаемыми большинством провайдеров. Сравнивая GMail с Web-интерфейсами корпоративных почто вых серверов, например Microsoft Outlook и Lotus Notes, нетрудно заметить, что GMail обеспечивает большинство функций, не прибегая к помощи тяже ловесных и ненадежных элементов ActiveX или Java-аплетов. В результате служба доступна не только для корпоративных пользователей, вооруженных специально настроенными машинами, но и для большинства обычных систем.

За GMail последовали другие интерактивные службы, например, Google Suggest, поисковый сервер которой автоматически предлагает завершение фразы, указываемой в составе запроса, и Google Maps — интерактивная мас штабируемая карта, посредством которой определяется расположение ресур са. Начали эксперименты с данной технологией и другие компании. В каче стве примера можно привести интерактивную систему Flickr, которая в на стоящее время является составной частью Yahoo!.

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

Наличие приложений, созданных на базе Ajax, свидетельствует о том, что новый подход получает признание разработчиков. Если отдельные програм мисты иногда используют новую технологию лишь для того, чтобы озна комиться с ней, то такие компании, как Google и Yahoo!, прибегают к ней только в том случае, если она сулит выигрыш в конкурентной борьбе. Мы уже обсуждали преимущества Ajax, которые следуют из теоретических рас суждений. В следующем разделе мы разберем Google Maps и выясним, как теоретические предпосылки реализуются на практике.

1.3.2. Google Maps Google Maps объединяет в себе черты средств просмотра и поискового сервера. Первоначально данная служба поддерживала только карту США (рис. 1.15), но впоследствии набор доступных регионов был расширен. За прос к карте формируется в текстовом формате;

допускается детализация до конкретной улицы и даже до таких заведений, как гостиницы или рестора на (рис. 1.16).

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

не исключено, что карта немного сдвинется в окне, чтобы наи лучшим образом разместить отображаемый текст. Прокрутка карты — одна из самых интересных особенностей Google Maps. Пользователь может пере таскивать всю карту с помощью мыши. Сама карта представляет собой мо заику, составленную из маленьких изображений, и если при прокрутке дол жен отобразиться новый фрагмент, он подгружается в асинхронном режиме.

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

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

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

В настоящее время уже существует приложение Google Earth, которое охватывает весь земной шар. — Примеч. ред.

56 Часть I. Новый взгляд на Web-приложение :ile Edit Siew So Bookmarks Iools Help ф| • '<:ф • $ 4? PjH SL Mtp //maps google com/ j Firefox Help _j Firefox Support. Ping-in FAQ Maps Map ) > Ш И Е т а Д Л Л l i n k t o t h i s p a g e Drag the mop with уоиг moose, or double cbck to center.

Exampl e s ear ches :

Go to a locution "kansasoly" trvfr.

-ТГ-Г-— 1 p^ "10 market st, san fraadsce* laaJt Find e business "T -1- f i t,. J « * "hotels near tax* try it "рига" try it Get dh actions "jB( to 350 bth. new york. ny" try it "sertile to 98109" try it Take a 0tir » Use our new Satellite feature? Try KavhoU» • Goose's 3D Earth.

. • » c » : w., T t Done Рис. 1.15. На исходной странице Google Maps отображаются масштабируемая карта США и поле ввода ключевых слов, знакомое пользователям поискового сервера Google. Заметьте, что средства масштабирования располагаются в верхней части карты, что позволяет пользователю изменять масштаб, когда карта находится в поле зрения Карты в Интернете — не новость. Но если мы обратимся к узлу подобного назначения, созданному задолго до появления Ajax, то увидим, что взаимо действие с пользователями реализовано совершенно по другим принципам Карта обычно разделена на фрагменты. Ссылки, управление масштабирова нием, как правило, расположены за пределами карты либо на обрамлении.

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

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

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

Ь обоих случаях карта представляется как набор простых изображений.

Глава 1. Каким должен быть Web-интерфейс !e Ed* View So Bookmarks Iools Help т ^i Ц# * mg ^ cf! sCl http //maps google com/ •* ©Go О, Q Firefox Help Q Firefox Support U Plug-in FAQ Maps Local Search Directions i '•"' " " ' p o t e l s n e a r l a x M a p s Map Q Pnnt 1Я Email m> [ink to this paqa C o u r t y a r d b y M a r r i o t t :

Radisson Lax L a x (310) 670 9000 - 0 2 на Е ( 3 1 0 ) 6 4 9 - 1 4 0 Courtyard by Marriott:

6 1 6 1 W C e n t u r y B l v d Torrance Plaza L o s A n g e l e s. C A 9 0 0 4 (310) 533-8000 -0.2 mi E h o t e l p m d c. n a t Courtyard bv Marriott: Lax D i r e c t i o n s : T o h a r e - P r o m h a r e (310)649-1400- 03 m В Sheraton Gateway (310)642-1111 -04 mil Crowne Plaza Los Angeles Airport (310) 642-7500-05 ire F Vagabond Inn (415) 776-7500- OS nsF 1 ft Starwood Hot el s & T Resorts { (310) 348-1800 -OVmiE Mandari n Oriental Hot el Group (310) 670-6422 - 0 m F Map dsta Д2005 NAV1EQ ^ Emb a s s y Suites Hotel § http jtmaps google com/ Рис. 1.16. Поиск гостиницы с помощью Google Maps. Обратите внимание на традиционное использование технологий DHTML для создания визуальных эффектов и подсказок. Запросы Ajax позволяют сделать процесс поиска более динамичным Классический Web-сервер по мере прокрутки пользователем карты посто янно обновляет шаблон, в то время как после запуска приложения Google Maps передаются лишь необходимые данные, в частности, изображения, от сутствующие в кэше. (В обоих случаях браузер кэширует изображения, но в классических приложениях содержимое кэша используется лишь для сни жения нагрузки на сеть.) Для интерактивных служб, таких как Google, про стота использования является основной характеристикой, определяющей, за хочет ли пользователь повторно обратиться к ней или предпочтет другой сервер. Другими словами, одним из ключевых показателей является впечат ление пользователя от документа. Улучшая интерфейс и придавая ему гиб кость, обеспечиваемую Ajax, компания Google заставила своих конкурентов задуматься о качестве их служб. Конечно же, нельзя упускать из виду дру гие факторы, например качество услуг, но при прочих равных возможностях Ajax может обеспечить существенное преимущество компании, использую щей эту технологию.

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

1.4. Альтернативные технологии Технология Ajax призвана удовлетворить потребность рынка в богатых кли ентах, обладающих высокими интерактивными возможностями и не требую щих инсталляции на локальных компьютерах. Однако Ajax — не единствен ная инфраструктура подобного назначения. Для некоторых задач она даже не является наилучшим выбором. В последующих разделах мы рассмотрим альтернативные решения.

1.4.1. Macromedia Flash Macromedia Flash — система, предназначенная для поддержки интерактив ных движущихся изображений. Она использует сжатые данные в форма те векторной графики. Изображения Flash могут воспроизводиться в про цессе загрузки, что позволяет пользователю просматривать первые фраг менты еще до окончания копирования данных. Данная система предостав ляет интерактивные возможности. Для их программирования используется ActionScript — язык, напоминающий JavaScript. Поддерживаются также ком поненты, обеспечивающие ввод данных. Технология Flash подходит для са мых разных применений — от компьютерных игр до сложных интерфейсов бизнес-приложений. В рамках данной технологии реализованы мощные сред ства поддержки графики, чем, к сожалению, не могут похвастаться базовые средства Ajax.

Технология Flash известна уже давно и поддерживается посредством встраиваемых модулей. В принципе, полагаться на модули, встраиваемые в клиентскую программу, не следует, однако модули, поддерживающие Flash, входят в комплект поставки большинства браузеров. Данная технология может использоваться на платформах Windows, Mac OS X и Linux, но средства, инсталлируемые в системе Linux, несколько уступают двум дру гим платформам.

Для создания богатых клиентов на базе Flash могут также использо ваться две дополнительные технологии: Macromedia Flex и пакет Laszlo. Обе они реализуют на стороне сервера базовый набор средств, предназначенный для генерации интерфейсов бизнес-приложений, и используют средства J2EE (Java 2 Enterprise Edition). Для динамического управления изображениями Flash на низком уровне предоставляются специальные инструменты, напри мер PHP-модуль libswf.

Глава 1. Каким должен быть Web-интерфейс 1.4.2. Java Web Start Java Web Start — это спецификация, определяющая способ связывания сер верных Web-приложений, созданных на базе Java. В результате программа, выполняемая на настольной системе, может находить, копировать и запус кать их. Допускается создавать гипертекстовые ссылки, указывающие на эти приложения;

такой подход обеспечивает обращение к ним из браузера, под держивающего Web Start. Средства Web Start включены в состав последних версий Java. В процессе инсталляции продуктов Internet Explorer и Mozilla по умолчанию разрешено использование данной технологии.

Единожды скопированное приложение Web Start хранится в составе фай ловой системы в так называемой "песочнице" и автоматически обновляется при получении новой версии. Такой подход допускает работу при отсутствии сетевого соединения и снижает объем трафика при повторной загрузке до кументов. В результате становится возможной работа с приложениями объе мом в несколько мегабайт. В приложениях используется цифровая подпись, и пользователь может решать, предоставлять ли им доступ к файловой си стеме, сетевым портам или к другим ресурсам.

Традиционно для создания интерфейса приложений Web Start использу ются средства Java Swing. Средствами Web Start могут доставляться ком поненты SWT (Standard Widget Toolkit), используемые в составе Eclipse, но чтобы добиться этого на практике, надо затратить дополнительные усилия.

На платформе.NET реализованы средства аналогичного назначения — No Touch Deployment. Они также обеспечивают простоту доставки, богатый пользовательский интерфейс и защиту.

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

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

60 Часть I. Новый взгляд на Web-приложение Системы клиент/сервер и n-связные архитектуры необходимы для взаи модействующих программ или для приложений, координируемых из едино го центра, но для них неизбежна задержка, связанная с передачей по сети, что снижает производительность работы пользователя. Предпринимаются попытки решить проблему задержки путем асинхронной удаленной обработ ки событий, но, несмотря на это, необходимо признать, что модель "запрос ответ", типичная для традиционных Web-приложений, в принципе не может обеспечить высокую производительность.

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

• Браузер имеет дело с приложением, а не с содержимым.

• Сервер доставляет данные, а не содержимое.

• Пользователь постоянно взаимодействует с приложением, и большинство запросов к серверу формируется без его участия.

• Код имеет большой объем, кроме того, он сложен и структурирован. Код играет главную роль в нашей архитектуре, поэтому ему надо уделять основное внимание.

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

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

• Впервые инфраструктура Ajax была упомянута 18 февраля 2005 г. в ста тье Джесса Джеймса Гарретта, которая доступна по адресу http: // www.adaptivepath.com/publications/essays/archives/000385.php.

• Рассуждения Алане. Купера о независимых и переходных приложениях можно найти в следующем документе: http://www.cooper.com/articles/ art_your_programs_posture.htm.

Глава 1. Каким должен быть Web-интерфейс Служба Google Maps доступна по следующим адресам.

Для жителей США: http://maps.google.com Для жителей Соединенного Королевства: http://maps.google.co.uk Для тех, кто живет на Луне: http: / /moon. google. com Изображения велосипеда получены с Web-узла Pedaling History, располо женного по адресу http://www.pedalinghistory.com.

Приложение Google Earth можно найти на сайте http://earth.google.com/. — Примеч. ред.

Знакомство с В этой главе...

• Технологии, лежащие в основе Ajax • Использование каскадных таблиц стилей для формирования внешнего вида документа • Использование Document Object Model для определения структуры пользовательского интерфейса • Асинхронное взаимодействие с сервером посредством XMLHttpRequest • Совместное использование базовых технологий в рамках инфраструктуры Ajax 64 Часть I. Новый взгляд на Web-приложение В главе 1 мы говорили о работе пользователей и о том, как Ajax может помочь им в повседневной деятельности. Большинство из нас занимаются разработкой программ, и, убедившись в том, что инфраструктура Ajax до стойна внимания, надо выяснить, как работать с ней. Несмотря на то что данный подход совершенно нов, ряд действий по созданию приложений уже знаком вам, особенно если вы имеете опыт работы с Интернетом.

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

Эту главу можно рассматривать как вводную, подобно разделам дру гих книг, в который обсуждается приложение "Hello, World!". Основная наша цель — добиться того, чтобы рассматриваемые примеры были работоспособ ны. Подробное обсуждение материала мы начнем в главе 3. Если вы уже знакомы с некоторыми технологиями, составляющими Ajax, то можете про пустить соответствующие разделы. Если же вы еще ничего не знаете об Ajax и не имеете опыта в программировании клиентских Web-программ, то ввод ный материал позволит вам лучше ориентироваться в остальной части книги.

2.1. Основные элементы Ajax Ajax — не одна конкретная технология, скорее это совокупность четырех технологий, дополняющих друг друга (табл. 2.1).

В главе 1 было показано, как сложные Ajax-приложения доставляются пользователям и как пользователи взаимодействуют с ними. Это достигает ся за счет использования JavaScript-кода, который "объединяет" приложение, определяет последовательность действий пользователя и бизнес-логику про граммы. Действия с интерфейсом преобразуются в операции с элементами DOM (Document Object Model), с помощью которых обрабатываются дан ные, доступные пользователю, в результате чего представление их изменяет ся. Здесь же производится обработка перемещений и щелчков мышью, а так же нажатий клавиш. Каскадные таблицы стилей, или CSS (Cascading Style Sheets), обеспечивают согласованный внешний вид элементов приложения и упрощают обращение к DOM-объектам. Объект XMLHttpRequest (или подоб ные механизмы) используется для асинхронного взаимодействия с сервером, обработки запросов пользователя и загрузки в процессе работы необходимых данных. Эти технологии и их взаимосвязь в рамках Ajax показаны на рис. 2.1.

Три из этих четырех технологий — CSS, DOM и JavaScript — состав ляют DHTML (Dynamic HTML). Следует заметить, что средства DHTML, появившиеся в 1997 году, подавали большие надежды, но так и не оправда ли их. DHTML позволяет создавать на базе Web-страниц интерфейсы с до статочно большими интерактивными возможностями, но любые изменения внешнего вида страницы реализуются лишь путем повторной загрузки всего документа. Набор действий, которые можно выполнить без обращения к сер веру, весьма ограничен. Средства DHTML интенсивно используются в Ajax, но благодаря асинхронным запросам можно получить результаты, которые невозможно получить с помощью обычных Web-страниц.

Глава 2. Знакомство с Ajax Таблица 2.1. Базовые технологии Ajax JavaScript — это язык сценариев общего назначения, JavaScript предназначенный для включения кода в Web-приложение.

Интерпретатор JavaScript в составе Web-браузера обеспечивает взаимодействие со встроенными средствами браузера. Данный язык используется для создания Ajax-приложений CSS предоставляет возможность определять стили CSS (Cascading Style Sheets) элементов Web-страницы. С помощью данной технологии можно без труда обеспечить согласованность внешнего вида компонентов приложения. В Ajax CSS используется для изменения представления интерфейса в процессе интерактивного взаимодействия DOM (Document Object Model) DOM представляет структуру Web-страницы в виде набора объектов, которые можно обрабатывать средствами JavaScript. Это дает возможность изменять внешний вид интерфейса Ajax-приложения в процессе работы Объект XMLHttpRequest позволяет программисту Объект XMLHttpRequest получать данные с Web-сервера в фоновом режиме. Как правило, возвращаемая информация предоставляется в формате XML, но данный объект позволяет также работать с любыми текстовыми данными. Несмотря на то что XMLHttpRequest является наиболее гибким из всех инструментов общего назначения, позволяющих решать подобные задачи, существуют и другие способы получения данных с сервера. Мы обсудим их в этой главе Очень валено, что средства поддержки всех рассматриваемых здесь тех нологий уже присутствуют в большинстве современных браузеров, включая Microsoft Internet Explorer, семейство Mozilla/Gecko, Firefox, Mozilla Suite, Netscape Navigator, Camino, Opera, Apple Safari и Konqueror (который ори ентирован на выполнение в среде Unix KDE). К сожалению, конкретные ре ализации этих технологий в разных браузерах различаются рядом важных деталей, более того, различия встречаются даже в разных версиях одного продукта. Правда, за последние пять лет положение дел несколько улуч шилось, и разработаны способы, позволяющие справиться с несовместимо стью браузеров.

В составе каждой современной операционной системы имеется браузер.

Таким образом, подавляющее большинство настольных и портативных ком пьютеров уже готово для запуска Ajax-приложений. Разработчики программ на базе Java или.NET могут лишь мечтать об этом. Браузеры для КПК и мобильных телефонов обычно имеют усеченный набор возможностей и не поддерживают полный набор Ajax-технологий. Следует заметить, что если бы средства поддержки Ajax и имелись в наличии, все равно размеры экра на и особенности ввода данных создавали бы существенные проблемы при работе с Ajax-приложениями. На сегодняшний день инфраструктура Ajax ориентирована лишь на настольные и портативные компьютеры.

66 Часть I. Новый взгляд на Web-приложение Рис. 2.1. Основные компоненты Ajax. JavaScript определяет бизнес-правила и поток выполнения. Document Object Model и каскадные таблицы стилей позволяют изменять внешний вид приложения в соответствии с данными, полученными с сервера в асинхронном режиме. Получение данных обеспечивается объектом XMLHttpRequest или другими подобными средствами Сначала мы рассмотрим технологии Ajax, независимо друг от друга, а затем поговорим об их взаимодействии. Если вы имеете опыт разработ ки Web-приложений, то материал, изложенный в данной главе, уже знаком вам. В этом случае вы можете перейти к главе 3, где мы обсудим вопросы управления данными технологиями с использованием образов разработки.

Разговор о технологиях, составляющих Ajax, начнем с JavaScript.

2.2. JavaScript изучался не зря Основным элементом Ajax несомненно является JavaScript. При работе Ajax приложения клиентская часть, включающая данные, средства их представ ления и программную логику, полностью копируется в память. Инструмен том для реализации программной логики является язык программирования JavaScript. Он несколько напоминает языки семейства С.

JavaScript можно охарактеризовать как язык сценариев общего назначе ния без поддержки типов. Отсутствие типов означает, что переменные не объ являются явно как строковые, целочисленные или объектные. Одной и той Глава 2. Знакомство с Ajax переменной можно присваивать значения различных типов. Например, у щие строки кода допустимы.

с ле д Ю ar х=3.1415926;

V x-'pi-"> Сначала при определении переменной х она инициализируется числом, а впоследствии ей же присваивается строковое значение.

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

var x=eval('7*5');

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

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

В среде, предоставляемой Web-браузером, процессору JavaScript доступ ны средства CSS, DOM и объекты XMLHttpRequest. В результате автор Web страницы может контролировать ее поведение программными средствами.

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

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

В наборе технологий, составляющих Ajax, язык JavaScript выполняет роль объединяющего элемента, обеспечивающего совместную работу других компонентов. Таким образом, чтобы написать Ajax-приложение, необходимо знать JavaScript. He имея опыта программирования на данном языке, невоз можно достичь успеха в использовании Ajax.

Теперь перейдем к рассмотрению каскадных таблиц стилей, которые поз воляют контролировать визуальное представление элементов Web-страницы.

68 Часть I. Новый взгляд на Web-приложение 2.3. Определение внешнего вида с помощью CSS Каскадные таблицы стилей, или CSS, часто используются не только в Ajax, но и в классических Web-приложениях. CSS позволяют централизованно опреде лять стили и применять их к элементам Web-страницы. В дополнение к таким понятиям, как цвет, обрамления, фоновые изображения, прозрачность и раз мер, таблицы стилей определяют способ взаимодействия элементов, в резуль тате чего удается обеспечить достаточно сложные визуальные эффекты.

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

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

Правило стиля состоит из двух частей: селектора и объявления стиля.

Селектор определяет, к каким элементам относятся стили, а объявление за дает свойства стилей, применяемых к этим элементам. Предположим, что мы хотим, чтобы заголовки первого уровня в составе документа (определенные посредством дескриптора <Н1>) выводились красным цветом. Для этого надо создать следующее правило:

hi { color: red } Здесь селектор имеет очень простой вид. Он сообщает о том, что данный стиль применим ко всем элементам <Н1>. Объявление стиля также просто;

оно модифицирует одно свойство. На практике и селекторы, и объявления стилей обычно бывают более сложными. Рассмотрим их возможные разно видности. Начнем с селекторов.

2.3.1. Селекторы CSS Помимо указания типов HTML-дескрипторов, к которым применяются сти ли, мы можем ограничить правило определенным контекстом. Задать кон текст молено различными способами: указывая тип HTML-дескриптора, тип класса или уникальный идентификатор элемента.

Рассмотрим сначала селекторы, которые задают типы дескрипторов. На пример, если вам надо применить рассмотренный выше стиль только к эле ментам <Н1>, которые содержатся внутри элементов

, приведенное выше правило примет следующий вид:

div hi { color: red;

} Такие селекторы называют также селекторами на базе элементов, так как при определении, должен ли стиль применяться к элементу DOM, учитыва Глава 2. Знакомство с Ajax ется тип элемента. Мы можем также определять классы, которые не связаны с типами HTML-дескрипторов. Например, чтобы, определить класс с именем callout, который присутствует в цветном блоке, надо написать следующее выражение:

.callout { border: solid blue lpx;

background-color: cyan } Для того чтобы связать класс с элементом, надо указать в составе HTML дескриптора атрибут class:

I'll appear as a normal bit of text
And I' l l appear as a callout!
С элементом можно связать несколько классов. Предположим, что мы определили класс loud следующим образом:

.loud { color: orange } Ниже показано, как можно применить стили, определенные посредством классов loud и callout, к элементам документа.

I'll be bright orange
I'11 appear as a callout
And I' l l appear as an unappealing mixture of both!

Текст, соответствующий третьему элементу

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

Сочетая классы и правила на основе элементов, есть возможность опре делять классы, которые будут воздействовать только на конкретные типы элементов. Например:

span.highlight { background-color: yellow } Этот стиль будет применим только к элементам , для которых ука зан атрибут highlight. К элементам без данного атрибута и к элемен там других типов, содержащим атрибут class=' highlight', правило приме няться не будет.

Классы можно сочетать с указанием родительских и дочерних элементов.

div.prose span.highlight { background-color: yellow } Это правило применимо только к элементам класса highlight, вложенным в элементы

класса prose.

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

#close { color: red } 70 Часть I. Новый взгляд на Web-приложение CSS также позволяет определять стили на базе псевдоселекторов. В бра узере определен ограниченный набор псевдоселекторов. Например, в резуль тате обработки представленного ниже выражения первая буква элемента бу дет иметь больший размер и отображаться полужирным шрифтом красно го цвета.

*: first-l etter { font-size: 500%;

color: red;

fl oat: l ef t ;

J Ограничить область действия этого правила можно следующим образом:

p.illuminated:first-letter { font-size: 500%;

color: red;

float: left;

} Теперь оно применяется только к элементам <р> класса illuminated. Ча сто используются псевдоселекторы first-l ine и hover. Последний изменяет внешний вид гипертекстовой ссылки, на которой располагается курсор мыши.

Например, чтобы при наведении курсора на ссылку она выделялась желтым цветом, надо создать следующее правило:

a:hover{ color:yellow;

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

2.3.2. Свойства стилей Стиль элемента HTML-страницы может быть задан различными способами.

Для универсальных элементов, например

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

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

.robotic{ font-size: 14pt;

font-family: courier new, courier, monospace;

font-weight: bold;

color: gray;

Глава 2. Знакомство cAjax Можно сократить запись, объединив элементы шрифта.

.robotic{ font: bold 14pt courier new, courier, monospace;

color: gray;

} В любом случае свойства стилей записываются в виде пар "ключ значение", которые отделяются друг от друга точкой с запятой.

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

.padded{ padding: 4px;

}.eccentricPadded { padding-bottom: 8рх;

paddi ng-top: 2рх;

paddi ng-l ef t : 2рх;

paddi ng-ri ght : 1брх;

margin: l px;

} Размеры элемента задаются свойствами width и height. Позиция элемен та может быть абсолютной или относительной. Абсолютная позиция указы вается с помощью свойств top и left и отсчитывается в пределах всей стра ницы. Относительная позиция вычисляется относительно других элементов.

Для указания цвета фона предусмотрено свойство background-color.

Кроме того, можно также определить фоновое изображение, указав свойство background-image.

.titlebar{ background-image: url(images/topbar.png);

} Элементы можно скрыть с помощью свойства visibility:hidden или display:none. Если задано выражение visibility:hidden, элемент не отоб ражается, но по-прежнему занимает место на странице, a display:none пол ностью удаляет элемент.

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

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

CSS выполняют две основные функции, связанные с созданием интер фейсных компонентов, подобных тем, которые показаны в правом окне на рис. 2.2. Рассмотрим каждую из этих функций.

72 Часть I. Новый взгляд на Web-приложение Рис. 2.2. Применение CSS для поддержки компонентов пользовательского интерфейса. Оба окна сгенерированы на основе одного и того же HTML-документа;

различаются только таблицы стилей.

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

Для внешнего элемента, представляющего само окно, задается абсолют ная позиция.

div.window{ position: absolute;

overflow: auto;

margin: 8px;

padding: Opx;

width: 42Opx;

height: 28Opx;

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

div.item{ position: relative;

height: 64px;

width: 5 6px;

I float: left;

padding: Opx;

margin: 8px;

} Элемент itemName, находящийся в составе элемента item, содержит текст, который располагается ниже пиктограммы. Это достигается установкой верх ней границы, равной высоте графического изображения.

div.item div.itemName{ margin-top: 48px;

font: lOpx verdana, arial, helvetica;

text-align: center;

Глава 2. Знакомство с Ajax Использование CSS для управления внешним видом компонентов Вторая задача, выполняемая средствами CSS, — это формирование внешнего вида элементов. Графическое представление элементов определяется именем класса, например:

div.folder { background:

transparent url(images/folder.png) top left no-repeat;

} div.filet background:

transparent url(images/file.png) top left no-repeat;

} div.special{ background:

transparent url(images/folder_important.png) top l ef t no-repeat;

} Для свойства background стиля пиктограммы задаются значения, запре щающие повторение. Изображение размещается в верхнем левом углу эле мента, и для него установлено значение прозрачности. (Окна, представлен ные на рис. 2.2, воспроизведены с помощью Firefox. Internet Explorer некор ректно поддерживает прозрачность изображений.png;

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

stuff
shoppi ng l i st Все изображения являются фоновыми. При определении стиля заголовка используется изображение, высота которого равна высоте строки, а ширина — одному пикселю. Для этого изображения задано повторение по горизонтали.

div.titlebar{ background-col or: #0066аа;

background-image: ur l (i mages/t i t l ebar _bg. png) ;

background-repeat : repeat -x;

Полностью HTML-код компонента показан в листинге 2.1.

74 Часть I. Новый взгляд на Web-приложение Листинг 2.1. Содержимое файла window.html

Documents
l ost and found
l
shopping list
things.txt
faves
chapter 2
HTML-разметка определяет не внешний вид, а лишь структуру докумен та. Она также указывает, к каким частям документа должно быть применено форматирование. Для этой цели используются имена классов, уникальные идентификаторы и типы самих дескрипторов. Просматривая HTML-код, мы видим, например, что одни элементы содержатся в составе других, но не мо жем сказать, как они будут выглядеть на экране. Редактируя таблицы стилей, можно изменить внешний вид документа, сохранив его структуру. Это видно на рис. 2.2. Таблицы стилей для компонента показаны в листинге 2.2.

Глава 2. Знакомство с Ajax Листинг 2.2. Содержимое файла window.сss div.window{ position: absolute;

overflow: auto;

background-color: feeefff;

border: solid #0066aa 2px;

margin: 8px;

padding: Opx;

/* 1 Размеры элемента */ width: 42Opx;

height: 280px;

} div.titlebar{ /* 2 Текстура фона */ background-color: #0066aa;

background-image:

url(images/titlebar_bg.png);

background-repeat: repeat-x;

color:white;

border-bottom: solid black lpx;

width: 100%;

height: 16px;

overflow:hidden;

} span.titleButton{ position: relative;

height: 16px;

width: 16px;

padding: Opx;

margin: Opx lpx;

Opx lpx;

/* 3 Выравнивание */ float:right;

} span.titleButtonfmin{ background: transparent url(images/min.png) top left no-repeat;

} span.titleButton#max{ background: transparent url(images/max.png) top left no-repeat;

} span.titleButton#close{ background: transparent url(images/close.png) top left no-repeat;

} div.contents { background-color: #e0e4e8;

overflow: auto;

padding: 2px;

height:240px;

} div.item{ position : relative;

height : 64px;

width: 56px;

float: left;

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

font-size: 18;

padding: Орх;

margin: 4px;

} div.item div.itemName { /* 4 Позиционирование текста */ margin-top: 48рх;

font: 10px verdana, arial, helvetica;

text-align: center;

} div.folder{ background: transparent url(images/folder.png) top left no-repeat;

} div.file{ background: transparent url(images/file.png) top l eft no-repeat;

} div.special{ background: transparent url(images/folder_important.png) top l ef t no-repeat;

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

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

\Л. Организация просмотра с помощью РОМ ЮМ (Document Object Model) представляет документ (Web-страницу) роцессору JavaScript. Благодаря DOM появляется возможность управ ять структурой документа (рис. 2.3) из программы. Такая возможность райне важна для разработчиков Ajax-приложений. В классическом Web риложении все содержимое окна браузера регулярно обновляется при по учении с сервера потока, содержащего HTML-данные. Подготавливая но ый вариант документа, можно существенно изменить интерфейс. В Ajax риложении большая часть изменений интерфейса осуществляется с помо щью DOM. HTML-элементы в составе Web-страницы составляют древовид ую структуру. Корнем данного дерева является дескриптор HTML, который редставляет весь документ. В нем содержится элемент BODY, соответству Глава 2. Знакомство с Ajax Рис. 2.3. HTML-документ представляется средствами DOM как древовидная структура, каждый элемент которой соответствует HTML-дескриптору ющий телу документа. Он, в свою очередь, является корнем отображаемой структуры. В теле документа находятся таблицы, абзацы, списки и прочие элементы, которые могут содержать другие дескрипторы.

DOM-представление Web-страницы также имеет древовидную структу ру, составленную из элементов, или узлов, которые содержат дочерние уз лы, и т.д. Процессор JavaScript представляет корневой узел текущей Web страницы посредством глобальной переменной document, которая выполняет роль стартовой точки для всех действий с DOM-данными. Структуру DOM определяет спецификация W3C. Для каждого элемента древовидной струк туры существует один родительский элемент, любое, в том числе нулевое количество дочерних элементов, и любое количество атрибутов, хранящих ся в ассоциативном массиве (т.е. массиве, для которого ключевым значением является не числовой индекс, а текст). На рис. 2.3 показана структура до кумента, код которого был представлен в листинге 2.2. Данная структура отображается с помощью инструмента Mozilla DOM Inspector (подробно он 78 Часть I. Новый взгляд на Web-приложение рассмотрен в приложении А).

Взаимосвязь элементов DOM отражает структуру HTML-документа и является двухсторонней. Изменение структуры DOM влияет на HTML разметку и, следовательно, на представление страницы.

Так выглядит DOM "на верхнем уровне". В следующем разделе вы увиди те, как структура DOM представляется интерпретатору JavaScript, и узнаете, как выполнять с ней требуемые действия.

2.4.1 Обработка DOM с помощью JavaScript В процессе работы пользователя с любым приложением возникает необходи мость изменять интерфейс. Это надо, например, для того, чтобы обеспечить обратную связь с пользователем (он должен видеть реакцию на свои дей ствия). Изменения могут потребоваться любые: замена текста статической метки или цвета одного из элементов, вывод диалогового окна и даже об новление значительной части окна и вывод нового набора компонентов. Ча ще всего приходится создавать древовидную структуру DOM, предоставляя браузеру HTML-данные (другими словами, формировать Web-страницу).

Документ, который был показан в листинге 2.2 и на рис. 2.3, достаточ но сложен. Мы же начнем обсуждение действий с DOM на простом приме ре. Предположим, что нам необходимо вывести приветствие пользователю.

При первой загрузке страницы мы еще не знаем его имени, поэтому нам понадобится изменить структуру документа несколько позже, добавив имя пользователя. Воздействовать на узлы DOM, вероятнее всего, придется из программы. В листинге 2.3 показан HTML-код простой Web-страницы.

Листинг 2.3. Страница Ajax-приложения hello

hel l o

В документе содержатся ссылки на два внешних ресурса: каскадные таб лицы стилей О и файл, содержащий JavaScript-код ©. Мы также определили пустой элемент div с идентификатором ©. С помощью программы мы можем 5ключить в его состав другие элементы.

Рассмотрим ресурсы, на которые ссылается документ. В CSS-файле опре делены простые стили, позволяющие выделять пункты списка и изменять Глава 2. Знакомство с Аjах шрифт и цвет. Содержимое CSS-файла приведено в листинге 2.4.

Листинг 2.4. Содержимое файла hel l o.css.declared{ color: red;

font-family: arial;

font-weight: normal;

font-size: 16px;

}.programmed!

color: blue;

font-family: helvetica;

font-weight: bold;

font-size: lOpx;

Мы определили два стиля для исходных DOM-узлов. (Имена стилей могут быть произвольными. В данном случае мы выбрали их так, чтобы упростить восприятие примера, но с таким же успехом мы могли использо вать имена fred и jim.) Ни один из этих стилей не используется в HTML доукменте, но они могут быть применены к элементам в результате выполне ния программы. В листинге 2.5 показан JavaScript-код для страницы, пред ставленной в листинге 2.4. Когда документ загружается, программа связы вает стиль с существующим узлом и создает новые DOM-элементы.

Листинг 2.5. Содержимое файла hel l o. j s window.onload=function(){ // Получение элемента по идентификатору var hello=document.getElementById('hello') ;

hello.className='declared' ;

var empty=document.getElementById('empty' );

addNode(empty,"reader of") ;

addNode(empty, "Ajax in Action!");

var children=empty.childNodes;

for (var i=0;

i

i++){ children[i].className='programmed' ;

} // Непосредственная установка стилей empty.style.border='solid green 2px';

empty.style.width="200px";

} function addNode(el,text){ // Создание нового элемента var childEl=document.createElement("div");

el.appendChild(childEl);

// Формирование текста var txtNode=document.createTextNode(text);

childEl.appendChild(txtNode);

80 Часть I. Новый взгляд на Web-приложение Код JavaScript сложнее для восприятия, чем HTML-документ или стили.

Точкой входа в данном случае является функция window.onload(), которая вызывается после загрузки всей страницы. К этому моменту древовидная структура DOM уже сформирована, и мы можем начинать работу с ней.

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

2.4.2. Поиск узла DOM Первое, что надо сделать для того, чтобы изменить структуру DOM из JavaScript-программы, — найти элементы, которые следует модифицировать.

Как было сказано ранее, в начале работы мы имеем лишь ссылку на корне вой узел в глобальной переменной document. Все остальные узлы DOM яв ляются дочерними (или более отдаленными потомками) document. Органи зовать пошаговый просмотр древовидной структуры большого документа — достаточно сложная задача. К счастью, ее можно упростить. Один из самых распространенных приемов — пометить элемент уникальным идентифика тором. В функции onloadO, код которой показан в листинге 2.5, мы орга низуем поиск двух элементов: абзаца, стиль которого изменяем, и пустого элемента

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

<р i d=' hel l o' > и

Заметьте, что данный метод принадлежит объекту Document. В простых случаях, подобных рассматриваемому, молено ссылаться на текущий объект Document посредством переменной document. При использовании IFrame по является несколько объектов Document, и приходится внимательно следить за тем, к какому из них осуществляется обращение.

В некоторых ситуациях необходимо организовать пошаговый обход дере ва DOM. Поскольку узлы DOM организованы в виде древовидной структу ры, каждый узел может иметь один родительский узел и любое число до черних узлов. Доступ к ним осуществляется с помощью свойств parentN ode и childNodes. Свойство parentNode ссылается на другой объект DOM, a childNodes — на JavaScript-массив узлов, которые приходится просматри вать по очереди.

Глава 2. Знакомство с Ajax var children=empty.childNodes;

for (var i=0;

Kchil dren. length;

i++){ Если требуемый узел не помечен уникальным идентификатором, поиск его осуществляется по-другому: с помощью функции getElementsByTagName.

Например, в результате вызова document.getElementsByTagName("UL") бу дет возвращен массив элементов UL, присутствующих в документе.

Последний способ применяется при работе с документом, структуру кото рого разработчик не может контролировать. Считается, что функция getEle mentByld дает более надежные результаты, чем getElementsByTagName (), по скольку при ее использовании не приходится учитывать структуру докумен та, которая может измениться.

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

Вернемся к листингу 2.5. В начале работы узел с идентификатором empty пуст. Когда документ загружается, мы динамически формируем содержи мое этого узла. В функции addNode () вызываются стандартные методы doc ument.createElement() и document.createTextNode(). Метод createEle ment (), которому в качестве параметра передается тип дескриптора, созда ет HTML-элемент.

var childEl=document.createElement("div") ;

Метод createTextNode () формирует DOM-узел, представляющий фраг мент текста. Этот узел обычно является дочерним по отношению к заголовку, элементу div, абзацу или пункту списка.

var txtNode=document.createTextNode("some text");

Согласно стандарту DOM текстовые узлы отличаются от узлов, представ ляющих HTML-элементы. К ним нельзя непосредственно применять стили, поэтому они занимают меньше памяти, чем обычные узлы. Стиль текста, со ответствующего текстовому узлу, определяется стилем родительского DOM элемента.

Чтобы созданный узел мог отображаться в окне браузера, его надо вклю чить в состав документа. Для этого предусмотрен метод appendChild().

el.appendChild(childEl) ;

Методов createElement(), createTextNode() и appendChild() достаточ но для добавления новых узлов в документу. Однако новые узлы нуждаются в стилях. Рассмотрим, какими способами можно добавить их.

82 Часть I. Новый взгляд на Web-приложение 2.4.4. Добавление стилей к документу До сих пор мы говорили о средствах, влияющих на структуру документа, и научились изменять статические HTML-данные. Кроме того, разработчику доступны методы, позволяющие изменять структуру таблиц стилей и, следо вательно, модифицировать из программы стили элементов.

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

Web-браузеры предоставляют средства, обеспечивающие необходимую точ ность при управлении интерфейсом из JavaScript-программы. Рассмотрим их более подробно.

Свойство className Если элементы стилей созданы в результате выполнения кода программы, мы можем воспользоваться свойством className узла DOM. Ниже приведена строка кода, в результате выполнения которой к узлу применяются стили, определенные посредством класса declared.

hello.className='declared' ;

Здесь hello — это ссылка на узел DOM. Таким способом можно связывать с узлом любое количество правил CSS и управлять сложными стилями.

Свойство style В некоторых случаях бывает необходимо изменить стиль конкретного эле мента, т.е. модифицировать стиль, уже заданный средствами CSS.

С каждым узлом DOM связан ассоциативный массив style, содержа щий информацию о стилях, установленных для данного узла. Как видно на рис. 2.4, в массиве стилей DOM-узла обычно содержится большое число эле ментов. Заметьте, что при присвоении значения свойству className узла ав томатически модифицируются значения в массиве style.

Значениями массива style можно управлять непосредственно. Ниже по казано, как отобразить рамку вокруг узла empty, задавая его стили.

empty.style.border="solid green 2px";

empty.style.width="200px";

Мы можем определить класс box и применить его посредством свойства className, но в ряде случаев описанный здесь подход проще и позволяет получить результаты быстрее. Кроме того, он позволяет формировать необ ходимые строки в программе. Если нам надо изменять размеры элементов с точностью до пикселя, то определять стили для значений ширины в интер вале от 1 до 800 слишком сложно и неэффективно.

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

Глава 2. Знакомство с Ajax Н Й Ь W o r l d !

Pages:     || 2 | 3 | 4 | 5 |   ...   | 11 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

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