Альтернативные AJAX-у методы передачи данных на сервер с сервера


Содержание

Технология AJAX

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

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

Асинхронность в случае AJAX можно представить в виде двух процессов: высокого приоритета и низкого. Первостепенным действием является процесс отображения страницы браузером. А второстепенным – обработка запросов пользователя сервером. В момент выполнения операций на стороне сервера, благодаря AJAX, браузер хотя и ждет ответа сервера, но не ограничивает работу пользователя со страницей.

Итак, концепция такова: между браузером и сервером не переставая происходит обмен данными, которые:

  1. Вводятся в браузер средствами пользовательского интерфейса;
  2. Отправляются на сервер;
  3. Обрабатываются на сервере, возможно, заносятся в БД;
  4. В это время браузер ожидает возвращение ответа;
  5. Пока браузер ждет, он не прекращает работу пользователя;
  6. Дождавшись данных от сервера в определенном формате, обрабатывает их и выводит в контент HTML страницы.

Вы можете пронаблюдать представленный процесс на схематической иллюстрации работы описываемой технологии.

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

  1. XML(eXtensible Markup Language) — расширяемый язык разметки;
  2. JSON(JavaScript Object Notation) —текстовый формат основанный на JavaScript.

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

Технология AJAX расшифровывается как (Asynchronous JavaScript and XML), из этого можно сделать вывод, что разработчики в первую очередь предполагают использование формата XML. Но на деле, как показывает практика все чаще используется формат JSON, в силу своего минимализма. Другими словами – работать с обоими форматами можно одинаково хорошо, но один и тот же набор данных, представленный в JSON и XML, в первом будет иметь меньший размер. Следовательно, если JSON имеет меньший размер, то и передаваться он будет быстрее, чем XML.

XML для AJAX

Чуть позже мы рассмотрим работу AJAX, с использованием данных в формате XML. А пока давайте разберемся, что же такое XML формат.

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

Во-вторых, синтаксис XML очень похож на всем нам известный HTML.

Вот пример HTML разметки:

Мы видим, что любой открытый тег имеет свой закрывающий эквивалент. Также некоторые из тегов имеют атрибуты. Тут я никому Америку не открыл, и все понимают, что этот HTML документ будет интерпретирован браузером, который вместо тегов применит соответствующие им стили для текста.

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

Пример структуры в формате XML

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

Запомните! Вся работа приложения на основе технологии AJAX сводится к обмену сложными структурами данных между клиентом (браузер), и сервером (web сервер).

Замечание 1: Можно, но совершенно не обязательно писать парсер самостоятельно ведь разработчики PHP создали все необходимые универсальные функции («XML Parser Functions») для работы с XML форматом. Чтобы разобраться с ними нужно начать копать в сторону xml_parser_create().

Замечание 2: Технологией AJAX, тоже предусмотрен механизм отправки пользовательских данных.

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

Отлично, теперь мы представляем, что такое XML формат, и понимаем, что назначением его является передача сложных структур данных между сервером и клиентом. Следовательно, можем двигаться дальше.

AJAX пример №1 (Начало работы)

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

Отправка всех полей формы на сервер с помощью ajax jQuery.

Как отправить данные с формы без перезагрузки страницы, да легко с помощью ajax.

Создадим простенькую форму:

Далее нам понадобится подключить jQuery

И делаем непосредственно наш Javascript

Ну и непосредственно (res.php) файл который будет принимать наши

данные и возвращать нам ответ:

Добавим на нашу страницу блок с атрибутом «results» куда будем выводить результат:

url (строка). Страница сервера, к которой будет сделан запрос.
type (строка: GET или POST). Тип запроса к серверу: GET или POS
data (строка). Данные, отправляемые на сервер.
cache (true или false). Включает или выключает кеширование браузером.
async (true или false). По умолчанию true. Включает или выключает асинхронные запросы

success вызывается, когда запрос завершился успешно. Ему передаются параметры: возвращаемые сервером данные, строка, содержащая код ответа сервера
error вызывается, когда запрос завершился неудачей. Передаются: xmlHttpRequest и строка, указывающая тип ошибки
complete вызывается, когда запрос завершился. Просто завершился, независимо от того, удачей или нет

Ajax+php получение данных

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

Отправил GET’ом значение showall на сервере подхватил его PHP.

После отработки PHP кода я генерирую шаблонную часть и передаю её обратно в блок с классом «foreach». С этим проблем нет.

Теперь вопрос: как мне в ajax ответе получить данные из PHP переменных $a,$b,$c заполненных в ходе работы скрипта. В данном случае нужно вставить содержимое переменной допустим $a в значение value

т.е. мне нужно понять как передается содержимое PHP переменных в JS для дальнейшей работы с содержимым.

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

Глава из книги “Ajax в действии”


Авторы: Дейв Крейн
Эрик Паскарелло
Даррен Джеймс
Источник: Ajax в действии
Материал предоставил: Издательство »Вильямс»

Опубликовано: 01.07.2006
Исправлено: 15.04.2009
Версия текста: 1.0

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

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

Помимо рассмотрения общих вопросов, связанных с работой приложения, мы также уделим внимание деталям взаимодействия между клиентом и сервером. В главе 2 вы получили основные сведения об объекте XMLHttpRequest и скрытых фреймах. В данной главе мы вернемся к этому вопросу и обсудим использование различных образов разработки для передачи данных клиенту и выясним, есть ли альтернатива разбору XML-документов с использованием методов DOM. В последнем разделе мы представим систему управления трафиком, связанным с обменом между клиентом и сервером в процессе работы приложения. На стороне клиента будет находиться очередь запросов, а на стороне сервера — процессы для их обработки.

Начнем разговор с рассмотрения роли сервера в Ajax-приложениии.

5.1 Программы, выполняемые на стороне сервера

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

Вторая задача сервера — это взаимодействие с клиентом: обработка запросов и подготовка ответов. Поскольку HTTP — единственный возможный в данной ситуации транспортный механизм, взаимодействие всегда должно начинаться по инициативе клиента. Сервер может только отвечать. В главе 4 мы говорили о том, что Ajax-приложение должно поддерживать модель предметной области как на стороне клиента (для обеспечения быстрого отклика), так и на стороне сервера (для доступа к ресурсам, например, к базе данных). Синхронизация этих моделей — сложная задача и клиент без помощи сервера не может справиться с ней. Вопросы работы сервера будут рассмотрены в разделе 5.5; там же будут предложены решения данной проблемы, основанные на использовании одного из образов разработки, описанных в главе 3.

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

5.2 Создание программ на стороне сервера

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

5.2.1 Популярные языки программирования

Для создания программного обеспечения, предназначенного для выполнения на стороне сервера, могут быть использованы различные языки. Несмотря на то, что вся история Internet очень коротка, отношение разработчиков к тем или иным языкам программирования не раз изменялись. В настоящее время чаще всего используются PHP, Java и классическая технология ASP; также становятся все более популярными ASP.NET и Ruby. Эти названия, конечно же знакомы большинству читателей. Ajax имеет дело преимущественно с клиентскими программным обеспечением, которое может взаимодействовать с серверными программами, написанными на любом из этих языков. Более того, при использовании Ajax становится не столь важно, какой именно язык применялся при создании серверных программ. В результате упрощается перенос Ajax-приложений с одной платформы на другую.

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

5.2.2 N-связные архитектуры

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

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

Первые системы Weв включали браузер, взаимодействующий с Web-сервером. Сервер обычно отвечал за передачу браузеру файлов, находящихся в файловой системе серверной машины.

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

Современное Web-приложение обычно имеет два основных уровня. Уровень бизнес-логики моделирует предметную область и непосредственно взаимодействует с базой данных. Уровень представления получает данные от средств бизнес-логики и представляет их пользователю. Браузер занимает в этой системе место низкоуровневого клиента.

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

Рис. 5.1. В Ajax-приложении некоторые функции уровня представления переместились со стороны сервера на сторону клиента. В результате возник новый уровень — клиентский уровень представления

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

5.2.3 Управление моделью предметной области на стороне клиента и на стороне сервера

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

Добавление дополнительного уровня всегда связано с увеличением сложности и возрастанию накладных расходов при взаимодействии. К счастью, данная проблема не нова. Аналогичные трудности возникали при разработке Web-приложений средствами J2EE, где были строго разделены уровень бизнес-логики и уровень представления. Модель предметной области поддерживается средствами бизнес-лоники. К ней обращается уровень представления, на котором затем генерируется содержимое Web-страниц, передаваемых браузеру. В J2EE проблема была решена путем применения “объектов передачи” (transfer objects), которые представляют собой обычные объекты, передаваемые между уровнями. Они представляют уровню представления ограниченный доступ к модели предметной области.

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

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

Согласно данным исследований (ссылка на соответствующий обзор приведена в конце данной главы), в настоящее время только для Java существует более 60 вариантов базовых средств разработки (по правде говоря, такое обилие предложений скорее мешает, чем помогает в работе). Большинство из них различается лишь в деталях и, независимо от языка реализации серверных программ, мы можем выделить для уровня представления несколько основных архитектурных принципов. Рассмотрим их.

5.3 Принципы создания программ на стороне сервера

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

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

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

5.3.1 Серверные программы, не соответствующие основным принципам разработки

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

Рис. 5.2. Web-программа, созданная без учета основных принципов разработки. Каждая страница, сервлет или CGI-сценарий поддерживает собственную логику и особенности представления данных. Вспомогательные методы и объекты могут инкапсулировать низкоуровневые функции общего назначения, например, обращение к базе данных

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

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

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

Илон Маск рекомендует:  Что такое код gettimeofday

5.3.2 Использование архитектуры Model2

Образ разработки Model2 является разновидностью MVC. Отличается он тем, что контроллер имеет единственную точку входа и единственное определение последовательности действий пользователя. В применении к Web-приложению, это означает, что одна страница контроллера или один сервлет отвечает за маршрутизацию большинства запросов, передавая их различным службам и пересылая полученные данные представлению. Среди базовых наборов средств, поддерживающих Model2, наиболее известным является Apache Struts. Данной архитектуре также соответствует ряд других инструментов для Java и PHP. На рис. 5.3 условно показано Web-приложение, соответствующее архитектуре Model2

Рис. 5.3. Архитектура Model2. Единственная страница контроллера или единственный сервлет получает все запросы и распределяет их в соответствии со схемой работы пользователя. Запрос может быть передан для обработки вспомогательным классам или функциям и, перед пересылкой браузеру, передается компоненту, выполняющему роль представления (например JSP- или PHP-документу)

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

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

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

5.3.3 Использование архитектуры на базе компонентов

При создании HTML-страницы для классического Web-приложения в распоряжении автора имеется ограниченный набор компонентов пользовательского интерфейса; обычно этот набор исчерпывается элементами HTML-формы. Их возможности остаются неизменными уже около 10 лет и они существенно проигрывают современным инструментам, предназначенным для создания интерфейсов. Если автор захочет реализовать нечто вроде древовидной структуры или таблицы с редактируемыми ячейками, он вынужден будет заняться низкоуровневым программированием. Это не идет ни в какое сравнение с уровнем абстракции, доступным разработчику, создающему программы для настольной системы и имеющему в своем распоряжении такие инструменты как MFC, GTK+, Cocoa, Swing или Qt.

Компоненты для Web

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

Рис. 5.4. Архитектура, основанная на использовании компонентов. Приложение описывается как набор компонентов, для воспроизведения которых браузеру передается поток HTML-данных и JavaScript-программ. Каждый компонент содержит собственные “микро-реализации” модели, представления и контроллера. Контроллер более высокого уровня обрабатывает запросы браузера к отдельным компонентам и модели предметной области

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

Одна из целей, преследуемых архитектурой, о которой идет речь — это формирование различных типов пользовательского интерфейса на базе единого описания. Некоторые наборы базовых средств, например, Windows Forms для .NET или JSF (JavaServer Faces) обеспечивают такую возможность.

Применимость архитектуры на базе компонентов для Ajax-приложений

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

Подобное решение хорошо подходит для тех приложений, для которых требуются лишь стандартные типы компонентов. Тем не менее, некоторая степень гибкости все же теряется. Успех Google Maps (см. главу 1) в значительной степени обусловлен тем, что для данной системы определен собственный набор компонентов, от прокручиваемой карты до элементов масштабирования и всплывающей подсказки. Реализовать ту же систему, используя стандартный набор компонентов, типичных для настольной системы, было бы гораздо сложнее и конечный результат наверняка получился бы гораздо худшим.

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

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

Будущее покажет, насколько хорошо удастся адаптировать системы на базе компонентов для Ajax. В настоящее время наблюдается рост интереса со стороны корпорации Sun и некоторых поставщиков JSF к инструментам, созданным с учетом Ajax. Поддержка некоторых функций, применимых для Ajax, уже реализована в .NET Forms; они также будут доступны в наборе инструментальных средств Atlas.(Ссылки на эти системы приведены в конце главы.)

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

5.3.4 Архитектуры, ориентированные на использование Web-служб



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

Термин Web-служба можно понимать как в широком, так и в узком смысле. Web-служба в узком смысле — это средства, использующие протокол SOAP. Web-служба в широком смысле — это любая система обмена данными, базирующаяся на протоколе HTTP, независимо от того, применяется ли при ее работе протокол SOAP или формат XML. XML-RPC, JSON-RPC и любая система, которую вы разработаете, используя объект XMLHttpRequest , будет Web-службой в широком смысле.

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

Предоставление доступа к объектам на стороне сервера

Многие инструментальные средства позволяют представить обычный объект, созданный на Java, C# или PHP, как Web-службу. При этом поддерживается отображения методов объекта в интерфейс Web-службы. Такую возможность предоставляют, в частности, Microsoft Visual Studio и Apache Axis for Java. Многие инструменты Ajax, например, DWR (для Java) и SAJAX (для PHP, .NET, Python и некоторых других языков) обеспечивают данную возможность посредством клиентского кода, написанного на языке JavaScript.

Применение инструментальных средств может существенно помочь при создании приложения. Если же использовать их неумело, результат будет противоположным. Для того, чтобы составить представление о правильном использовании инструментов, рассмотрим простой пример, в котором применяется Java DWR. Мы определим объект на стороне сервера для представления персональной информации.

Данный объект должен соответствовать спецификации JavaBeans. Это означает, что он должен предоставлять конструктор, вызываемый без параметров и обеспечивать доступ к требуемым полям для чтения и записи посредством get- и set-методов. Далее мы сообщаем DWR о том, что данный объект должен быть доступен уровню JavaScript. Для этого мы редактируем файл dwr.xml.

В разделе init мы определяем средства преобразования нашего класса в тип bean, а в разделе allow определяем средства, представляющие данный объект JavaScript-программам в виде переменной person . Наш объект Person содержит только один общедоступный метод, getName() , таким образом мы можем включить в код клиента Ajax следующее выражение.

Затем можно получать требуемое значение с сервера в асинхронном режиме.

В нашем классе Person содержится только один метод. На первый взгляд может показаться, что им и исчерпывается набор средств, которые предоставляются клиенту. На самом деле это не так. Класс Person является подклассом java.lang.Object и наследует от него ряд общедоступных методов, например, hashCode() и toString() . К ним также может производиться обращение. Эти “скрытые” средства не являются специфическими для DWR. Метод JSONRPCBridge.registerObject() , например, делает тоже самое. Следует заметить, что DWR позволяет ограничить доступ к определенным методам, настраивая конфигурационный XML-файл. Однако по умолчанию доступ предоставляется ко всем методам. Такая проблема типична для решений, основанных на отражении. Мы встретились с ней в главе 4 при создании первых вариантов ObjectViewer . Рассмотрим способы ее решения.

Предоставление ограниченного доступа

Если мы ненамеренно дадим возможность пользователям Web вычислять хэш-коды наших объектов, может ли это представлять опасность для нас? Для рассматриваемого примера, по-видимому, нет, так как суперклассом создаваемого нами класса является java.lang.Object , и эта ситуация вряд ли изменится. Для более сложных моделей, предоставляя информацию о суперклассе, мы не гарантируем, что программа в дальнейшем не подвергнется реструктуризации. Вполне может получиться так, что разработчик клиентской программы захочет воспользоваться методами, доступ к которым вы непреднамеренно предоставили. Затем, когда реструктуризированная модель будет доставлена на сервер, программные средства на стороне клиента внезапно откажутся работать. Другими словами, такое решение препятствует корректному разделению функций между клиентом и сервером. Если вы используете инструментальные средства, подобные DWR или JSON-RPC, вам следует тщательно взвешивать решения относительно состава интерфейса Ajax. Возможно, вам даже придется создать нечто вроде объекта Facade (рис. 5.5).

Рис. 5.5. Одна из систем предоставляет Ajax-клиенту все объекты как Internet-службы, а при создании другой использован образ разработки Facade, который гарантирует доступ лишь к ограниченному набору функций. Уменьшая число общедоступных методов мы снижаем риск повредить клиентский код при реструктуризации серверных программ

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

Еще одно преимущество Facade состоит в том, что данный образ разработки позволяет определять степень детализации предоставляемых услуг. Хорошая модель предметной области обычно содержит большое количество методов, выполняющих несложные действия. Таким образом удовлетворяется требование детального управления работой кода на стороне сервера. Ajax-клиент предъявляет к интерфейсу Web-службы совершенно другие требования; они вытекают из наличия задержки, связанной с передачей данных по сети. Большое количество методов, решающих частные задачи, резко снизят практичность клиента, а сервер может не справиться с большим количеством запросов, передаваемых по сети.

Различие требований к интерфейсу, предъявляемым клиентом и сервером можно проиллюстрировать на примере. Сравним разговор с обменом письмами. (Говоря о письмах мы имеем в виду не электронную почту, а именно письма, написанные на бумаге, доставка которых занимает несколько дней.) Когда два человека беседуют, как минимум несколько фраз. которыми они обмениваются друг с другом, посвящена стандартной теме “как дела?”. При написании письма никто не позволяет себе задать один подобный вопрос и ждать ответа на него. Отправитель подробно описывает, как его здоровье, как он провел отпуск, какие новости он узнал недавно — все это оформляется в виде одного документа.

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

Типичный документ, например, данная книга, состоит из абзацев, заголовков, таблиц и рисунков. Аналогично, документ, содержащийся в в обращении к службе, может содержать различные элементы, например, запросы, данные для обновления и оповещения. Образ разработки Command, который обсуждался в главе 3, позволяет представлять структуру документа в виде последовательности действий (которые при необходимости можно отменять), передаваемых между клиентом и сервером. Реализация подобной структуры будет рассмотрена далее в этой главе.

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

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

5.4 Частные решения: обмен данными

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

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

5.4.1 Взаимодействие, затрагивающее только клиентскую программу

Данный тип взаимодействия характеризуется тем, что действия пользователя обрабатываются сценарием, выполняющемся в среде браузера. Обращаться к ресурсам на стороне сервера (в частности, к уровню представления) нет необходимости, а это позволяет обеспечить быстрый отклик приложения и снижает нагрузку на сервер. Подобное взаимодействие подходит для несложных вычислений, например, для подсчета общей суммы товаров, заказанных пользователем. Для того, чтобы такой подход дал желаемые результаты, программы, расположенные на стороне клиента и поддерживающие взаимодействие, не должны меняться в течение сеанса работы пользователя и объем их должен быть небольшим. Для приложения, предназначенного для поддержки интерактивного магазина, эти требования выполняются автоматически. Число изделий, предлагаемых пользователю, относительно невелико (по крайней мере, не тысячи пунктов, как в случае библиотеки) и цены на товары не меняются каждую минуту (в отличие, например, от котировок акций на бирже). Данный тип взаимодействия уже обсуждался в главе 4 при рассмотрении контроллера, расположенного на стороне клиента, поэтому мы больше не будем уделять ему внимание.

Остальные три категории предполагают обращение к серверу и отличаются в основном передаваемыми данными. Главные различия между этими типами взаимодействия описаны в последующих разделах; там же рассмотрены преимущества и недостатки каждого из них.

5.4.2 Пример отображения информации о планетах

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

Рис. 5.6. По щелчку на пиктограмме, соответствующей планете, информация о ней выводится в окне

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

В состав нашего файла мы включили несколько JavaScript-библиотек (111). Средства, предоставляемые net.js , обеспечивают поддержку низкоуровневых HTTP-запросов, используя для этой цели объект XMLHttpRequest , который обсуждался в главе 2. В файле windows.js определен объект окна, допускающего перетаскивание. Это окно мы используем для отображения информации. Детали реализации окна в данном случае не имеют значениями; нас интересует только порядок вызова конструктора.

Здесь bodyDiv — это элемент DOM, который выводится в окне, title — строка, отображаемая в заголовке окна, а параметры x , y , w и h определяют начальные размеры окна. Задавая элемент DOM в качестве параметра, мы обеспечиваем достаточную гибкость при отображении данных к окне. Полностью код объекта Window можно скопировать с Web-узла, посвященного данной книге. Посредством HTML-кода, содержащегося в файле, мы определяет элемент div для каждой планеты (333), а в функции window.onload (222) мы связываем с пиктограммами планет обработчики onclick . В качестве обработчиков используются функции showInfo() , которые в данном листинге не определены. В этой главе мы обсудим несколько вариантов их реализации. Рассмотрим действия, которые мы можем предпринять тогда, когда нам требуется загрузка данных.

5.4.3 Взаимодействие, ориентированное на содержимое

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

Общие сведения

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

Рис. 5.7. Архитектура Ajax-приложения, ориентированная на содержимое. Клиент создает элемент IFrame и передает серверу запрос на получение информации. Содержимое генерируется моделью, представлением и контроллером уровня представления и возвращаются элементу IFrame. На уровне клиента никакие требования к модели предметной области не предъявляются

Илон Маск рекомендует:  Какой лучший редактор HTML, PHP, CSS, JS кода

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

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

Мы определили объект ContentPopup , который генерирует универсальный объект Window , создает элемент IFrame , предназначенный для просмотра содержимого, и загружает в него ресурс, определяемый URL. В данной ситуации мы лишь формируем имя статического HTML-файла и оформляем его в виде URL. В более сложном случае, если данные генерируются динамически, нам, возможно придется добавить к URL строку параметров. Простой файл, предназначенный для отображения в составе IFrame (листинг 5.3) генерируется сервером.

В данном документе нет ничего примечательного: мы лишь используем обычный HTML-файл, как и для классического Web-приложения.

При использовании архитектуры, ориентированной на содержимое, клиенту требуется лишь ограниченная информация о бизнес-логике приложения, достаточная для размещения элемента IFrame и формирования URL, определяющего содержимое для загрузки. Связь между клиентом и уровнем представления очень слабая; основная ответственность за предоставление содержимого возлагается на сервер. Преимущество данного типа взаимодействия состоит в том, что оно позволяет использовать готовые HTML-документы. Он может оказаться полезен в двух случаях: при включении содержимого, предоставляемого внешними узлами, например, информации, получаемой от деловых партнеров, и при отображении данных, полученных от уже существующих приложений. В этих случаях использование формата HTML может обеспечивать высокую эффективность и как правило не возникает необходимости преобразовывать информацию в другой вид. В качестве примера можно привести документы, содержащие справочную информацию. Использовать в приложениях Ajax подход, ориентированный на содержимое, целесообразно в тех случаях, когда в классических приложениях применяются всплывающие окна. Тем не менее, данная архитектура имеет ограниченное применение. Причины этого нетрудно понять, зная ее недостатки.

Проблемы и ограничения

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

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

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

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

Варианты применения подхода, ориентированного на содержимое

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

5.4.4 Взаимодействие, ориентированное на сценарий

Когда мы организуем передачу с сервера JavaScript-файла и выполнение этого файла в среде браузера, мы можем утверждать, что решаемая нами задача нетривиальна. Если JavaScript-код, предназначенный для передачи, генерируется программой, то выполняемые действия еще более сложны. Традиционно клиентские и серверные программы обмениваются данными друг с другом. Передача по сети исполняемого кода, обеспечивает дополнительную гибкость. Поддержка мобильного кода реализована лишь в инструментах, предназначенных для создания корпоративных приложений, например, Java и .NET. Для этой цели специально предусмотрены технологии RMI, Jini, и .NET Remoting Framework. Разработчики же простых Web-приложений решают подобные задачи постоянно! Логично предположить, что Ajax расширит наши возможности по работе с мобильным кодом.

Общие сведения

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

Рис. 5.8. Архитектура Ajax-приложения, ориентированная на сценарии. Клиентская программа передает серверу запрос на получение фрагмента JavaScript-кода. Полученный код интерпретируется. На стороне клиента обеспечиваются точки входа для сгенерированных сценариев, что позволяет сценарию управлять клиентской программой

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

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

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

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

Мы определили функцию showPopup() , которая получает два параметра и создает объект окна. В листинге 5.5 приведен пример сценария, вызывающего эту функцию.

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

Загрузка сценариев в элементы IFrame

Если мы загрузим JavaScript-код, используя HTML-дескриптор

Технология AJAX, примеры скриптов

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

Сегодня я сделаю упор на работу с XML данными, т.к. пытаясь разобраться с технологией AJAX, мне попадались лишь примеры работы с JSON форматом. О работе с ним читайте в продолжении к данному материалу, которое скоро будет подготовлено и опубликовано.

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

  1. Технология AJAX пример №1 — наипростейший пример, для ознакомления с азами AJAX.
  2. Технология AJAX пример №2 — отправка данных на сервер средствами AJAX.
  3. Технология AJAX пример №3 — отправка структуры данных с сервера в виде XML и работа с ними на стороне клиента.

Совместив все эти AJAX примеры воедино, мы получим реализацию обмена данными по AJAX технологии с форматом XML.

Давайте приступим к большой и трудоемкой работе. Но сначала ознакомьтесь с небольшим введением.

За интерактивностью будущее!

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

Дать пользователю свободу действий – и не перезагружать страницу, стало возможным с развитием и внедрением AJAX технологии.

Концепция технологии AJAX

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

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

Под асинхронность относительно AJAX можно представить, что первостепенным действием является процесс отображения страницы браузером. А второстепенным – обработка запросов пользователя сервером. В момент выполнения операций на стороне сервера, благодаря аяксу, браузер ждет ответа, не ограничивая работу пользователя со страницей.

Итак, концепция такова: между браузером и сервером не переставая происходит обмен данными, которые:

  1. Вводятся в браузер средствами пользовательского интерфейса;
  2. Отправляются на сервер;
  3. Обрабатываются на сервере, возможно, заносятся в БД;
  4. В это время браузер ожидает возвращение ответа;
  5. Пока браузер ждет, он не прекращает работу пользователя;
  6. Дождавшись данных от сервера в определенном формате, обрабатывает их и выводит в контент HTML страницы.

Вы можете пронаблюдать представленный процесс на схематической иллюстрации работы описываемой технологии.

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

  1. XML(eXtensible Markup Language) — расширяемый язык разметки;
  2. JSON(JavaScript Object Notation) —текстовый формат основанный на JavaScript.

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

Технология AJAX расшифровывается как (Asynchronous JavaScript and XML), из этого можно сделать вывод, что разработчики в первую очередь предполагают использование формата XML. Но на деле, как показывает практика все чаще используется формат JSON, в силу своего минимализма. Другими словами – работать с обоими форматами можно одинаково хорошо, но один и тот же набор данных, представленный в JSON и XML, в первом будет иметь меньший размер. Следовательно, если JSON имеет меньший размер, то и передаваться он будет быстрее, чем XML.

XML для AJAX

Чуть позже мы рассмотрим работу AJAX, с использованием данных в формате XML. А пока давайте разберемся, что же такое XML формат.

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

Во-вторых, синтаксис XML очень похож на всем нам известный HTML.

Вот пример HTML разметки:

Мы видим, что любой открытый тег имеет свой закрывающий эквивалент. Также некоторые из тегов имеют атрибуты. Тут я никому Америку не открыл, и все понимают, что этот HTML документ будет интерпретирован браузером, который вместо тегов применит соответствующие им стили для текста.

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

Пример структуры в формате XML

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

Запомните! Вся работа приложения на основе технологии AJAX сводится к обмену сложными структурами данных между клиентом (браузер), и сервером (web сервер).

Замечание 1: Можно, но совершенно не обязательно писать парсер самостоятельно ведь разработчики PHP создали все необходимые универсальные функции («XML Parser Functions») для работы с XML форматом. Чтобы разобраться с ними нужно начать копать в сторону xml_parser_create().

Замечание 2: Технологией AJAX, тоже предусмотрен механизм отправки пользовательских данных.

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

Отлично, теперь мы представляем, что такое XML формат, и понимаем, что назначением его является передача сложных структур данных между сервером и клиентом. Следовательно, можем двигаться дальше.

AJAX пример №1 (Начало работы)

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

Исходный код HTML документа:

script type = «text/javascript» >
function startAjax ( url ) <
var request ;
if ( window. XMLHttpRequest ) <
request = new XMLHttpRequest ( ) ;
> else if ( window. ActiveXObject ) <
request = new ActiveXObject ( «Microsoft.XMLHTTP» ) ;
> else <
return ;
>

request. onreadystatechange = function ( ) <
switch ( request. readyState ) <
case 1 : print_console ( «
1: Подготовка к отправке. » ) ; break
case 2 : print_console ( «
2: Отправлен. » ) ; break
case 3 : print_console ( «
3: Идет обмен..» ) ; break
case 4 : <
if ( request. status == 200 ) <
print_console ( «
4: Обмен завершен.» ) ;
document. getElementById ( «printResult» ) . innerHTML = «» + request. responseText + «» ;
> else if ( request. status == 404 ) <
alert ( «Ошибка: запрашиваемый скрипт не найден!» ) ;
>
else alert ( «Ошибка: сервер вернул статус: » + request. status ) ;

break
>
>
>
request. open ( ‘GET’ , url , true ) ;
request. send ( » ) ;
>
function print_console ( text ) <
document. getElementById ( «console» ) . innerHTML += text ;
>
script >

В коде HTML страницы мы создаем функцию startAjax() на языке JavaScript, позволяющую реализовать задуманные действия с AJAX’ом. Кстати, о действиях, во-первых мы хотим увидеть, как отрабатывает php скрипт, находящийся на сервере. Во-вторых, как возвращенная им информация появляется на страничке, без перезагрузки. Для этого в коде мы предусмотрели ссылку, по нажатию на которую запустится процесс всей демонстрации, консоль вывода действий JavaScript скрипта, а также блок для вывода результата.


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

  • Создаем объект XMLHttpRequest позволяющий получать данные с сервера в фоновом режиме.
  • Если используется IE (Браузер — Internet Explorer) тогда вместо вышеупомянутого объекта XMLHttpRequest, создаем объект ActiveXObject, смысл у них единый, отличие только в индивидуальности для IE.
  • Обрабатываем все 4-ре статуса состояния запроса. Созданный запрос он же объект request, в процессе отправки\получения данных может принимать четыре состояния (1подготовка к отправке, 2отправлен, 3идет обмен, 4получен ответ.)
  • В случае 4-го статуса, при получении ответа от сервера, происходит проверка на тип ответа 200«OK» или 404«Not Found».
  • Событие request.open() — открывает соединение с сервером с указанием метода передачи данных, адресом запроса, и флагом асинхронности. Указав флаг как false, мы получим в результате обычную перезагрузку страницы.

Кликнув на ссылку, мы пронаблюдаем успешное выполнение простого AJAX запроса.

Разумеется, такое сообщение мы получим только после того как разместим на сервере, в той же папке, что и саму html страничку, скрипт handler_script.php:

Скрипт не мудрый, тем не менее, его содержимого достаточно для демонстрации.

Ну вот, с азами разобрались, перейдем от простого к сложному. Рассмотрим пример использования технологии AJAX по прямому её назначению, а именно с пересылкой данных в виде XML.

AJAX пример №2 — отправка POST запроса на сервер

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

  • GET — передаёт пользовательских данные заданному ресурсу по URI.
  • POST — передаёт пользовательских данные заданному ресурсу по протоколу.
  • HEAD — аналогичен методу GET, за исключением того, что сервер ничего не посылает в информационной части ответа.
  • TRACE — возвращает всё, что было введено при запросе, включая HTTP-заголовки.
  • DELETE — Удаляет указанный ресурс.
  • PUT — загружает содержимого запроса на указанный в запросе URI.

Причем это относится не только к технологии AJAX, а в принципе ко всему протоколу HTTP. Самыми распространенными являются два типа GET и POST, как правило, они широко используемы в отправке данных на сервер посредствам HTML элемента form. Именно с этими типами запроса я и приведу примеры работы веб приложения на АЯКСЕ.

Для того чтобы с помощью АЯКС технологии отправить POST запрос, нужно использовать три метода объекта request:

  • open – открывает соединение с сервером с указанием метода передачи данных.
  • setRequestHeader — устанавливает заголовок запроса.
  • send — отправляет запрос.

Откройте код примера №1 и замените в нем строки:

Краткое руководство по AJAX

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

С помощью AJAX можно создавать Web-приложения, которые будут лучше, быстрее и удобнее для пользователей, чем существующие.

AJAX основывается на JavaScript и запросах HTTP .

AJAX = Асинхронный JavaScript и XML

AJAX является сокращением от «Asynchronous JavaScript And XML» (Асинхронный JavaScript и XML).

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

AJAX использует JavaScript для отправки и получения данных при взаимодействии Web-браузера и Web-сервера.

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

AJAX является технологией браузера

AJAX является технологией, которая выполняется в браузере клиента. Она использует асинхронную передачу данных (запросы HTTP) между браузером и Web-сервером, позволяя Web-страницам запрашивать с сервера небольшие объемы данных вместо целых страниц.

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

AJAX является технологией Web-браузера, которая не зависит от программного обеспечения Web-сервера.

AJAX основан на открытых стандартах

AJAX использует следующие открытые стандарты:

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

Технология AJAX улучшает приложения Интернет

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

Однако приложения Интернет не всегда бывают достаточно «богаты» свойствами и удобны для использования по сравнению с традиционными приложениями.

С помощью AJAX приложения Интернет можно сделать богаче (меньше, быстрее, и легче в использовании).

AJAX можно использовать прямо сейчас

Нет ничего нового, что требует изучения.

Технология AJAX основывается на открытых стандартах. Эти стандарты использовались множеством разработчиков многие годы.

Большинство существующих Web-приложений можно легко переписать с помощью технологии AJAX вместо традиционных форм HTML.

AJAX использует XML и запросы HTTP

Традиционное Web-приложение посылает введенные данные на Web-сервер (используя форму HTML). После обработки данных Web-сервер возвращает пользователю совершенно новую Web-страницу.

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

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

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

Как это делается, будет показано далее в этом кратком руководстве.

Пример использования AJAX

Технологию AJAX можно использовать для создания приложений с большими интерактивными возможностями.

Пример AJAX

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

Описание примера

На странице выводится поле ввода с предложением ввести имя. Когда пользователь начинает вводить в этом поле имя, ниже появляются возможные варианты имен.

Форма HTML

Пусть на Web-странице имеется форма HTML со следующим кодом:

Как можно видеть, это простая форма HTML с полем ввода с именем «txt1».

Атрибут события этого поля ввода определяет функцию, которая будет запускаться при возникновении события onkeyup.

Параграф ниже формы содержит тег span с именем «txtHint». Тег span используется в качестве поля для подстановки данных, получаемых с Web-сервера.

Когда пользователь вводит данные, выполняется функция с именем «showHint()». Выполнение функции запускается событием «onkeyup». Другими словами, всякий раз, когда пользователь убирает свой палец с клавиатуры внутри поля ввода (отпускает нажатую клавишу), вызывается функция showHint .

Функция showHint()

Функция showHint() является очень простой функцией JavaScript, помещенной в раздел заголовка страницы HTML.

Функция имеет следующий код:

Функция выполняется всякий раз, когда в поле ввода вводится символ.

Если имеется какой-то ввод в текстовое поле ( str.length > 0 ), то функция выполняет следующее:

  • Определяет url (имя файла) для отправки на сервер
  • Добавляет к url параметр ( q ) с содержимым поля ввода
  • Добавляет случайное число, чтобы сервер не использовал кэшированный файл
  • Создает объект XMLHTTP, и приказывает объекту выполнить функцию с именем stateChanged , когда произойдет изменение.
  • Открывает объект XMLHTTP с заданным url.
  • Посылает запрос HTTP на сервер

Если поле ввода будет пустым, то функция просто очищает содержимое поля для подстановки txtHint .

Функция stateChanged()

Функция stateChanged() содержит следующий код:

Функция stateChanged() выполняется всякий раз, когда изменяется состояние объекта XMLHTTP.

Когда состояние будет равно 4 (или «complete»), поле для подстановки txtHint получает содержимое текста пришедшего ответа.

AJAX с помощью jQuery. Руководство для начинающих. Часть 1

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

Илон Маск рекомендует:  Функции muscat

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

В данной серии уроков мы рассмотрим основы построения запросов AJAX с помощью jQuery. Будут раскрыты следующие темы:

  • Что такое технология AJAX? Как она работает? В чем ее преимущества?
  • Как выполнить различные типы запросов AJAX с помощью jQuery?
  • Отправка данных на сервер с помощью запросов AJAX.
  • Обработка и выделение данных из ответов AJAX с сервера.
  • Как настроить обработку AJAX в jQuery и изменить установки по умолчанию?

Примечание: Уроки сконцентрированы на части JavaScript клиентской стороны. Но разработка серверной части также достаточно проста. Для более полной информации следует изучить материалы по языкам программирования серверной стороны, например PHP.

Что такое AJAX и чем он полезен?

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

  • Обычная веб страница содержит ссылки или формы, которые при нажатии или отправке создают запрос к новому адресу URL на веб сервере. Сервер отправляет полностью новую страницу HTML, которую затем выводит браузер, заменяя оригинальную страницу. Такой подход занимает много времени и плохо действует на посетителя, так как тому приходится ждать загрузки новой страницы.
  • При использовании технологии AJAX, JavaScript код делает запрос к URL на сервере. Код также может отправить данные вместе с запросом. Затем JavaScript код обрабатывает ответ сервера и действует соответствующим образом. Например, могут быть произведены вычисления с возвращаемыми данными, добавлен или обновлен виджет на странице, выдано сообщение посетителю об обновлении базы данных на сервере.

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

Фундаментальным моментом AJAX является объект JavaScript XMLHttpRequest . Он предоставляет ряд методов, таких как open() , send() и onreadystatechange() , которые могут быть использованы при отправке запросов AJAX на сервер и обработке ответов в фоновом режиме.

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

Для тех кто более любопытен, слово AJAX является аббревиатурой из первых букв выражения на английском языке «Asynchronous JavaScript And XML» (Асинхронный JavaScript и XML). Однако, термин может ввести в заблуждение — запрос не обязательно должен быть асинхронным и необязательно использовать XML для отправки данных.

Делаем запрос GET с помощью $.get()

Метод jQuery $.get() предоставляет легкий и удобный способ сделать простой запрос AJAX. Он выполняет запрос с помощью метода HTTP GET (используется для получения URL, например страниц и изображений), вместо метода POST (который традиционно используется для отправки данных формы).

В простейшей форме можно вызвать метод так:

. где url является адресом URL ресурса, от которого ожидается ответ. Обычно это скрипт на стороне сервера, который выполняет какие-нибудь действия и может возвращать некие данные:

. хотя можно также запросить статический документ:

При запросе URL, вы можете отправить данные с запросом. Вы можете передать данные в строке запроса, так же как и при обычном запросе GET:

Корректно будет сделать то же самое передав объект данных в качестве второго параметра методу $.get() . Объект данных должен содержать информацию в виде пар имя свойства/значение свойства. Например:

В качестве альтернативы вы можете передать данные методу $.get() как строку:

Получаем данные с сервера

До сих пор мы рассматривали примеры использования $.get() только для отправки запросов на сервер, игнорируя любой ответ, который может сформировать скрипт на серверной стороне. Но в большинстве случаев ваш JavaScript код будет ожидать ответ от скрипта на серверной стороне и обрабатывать полученные данные.

AJAX запрос — асинхронный , что означет его выполнение в фоновом режиме, когда остальной код JavaScript продолжает действовать. Как же в таком случае получать ответ от сервера, когда завершится запрос?

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

Как только возвратная функция создана, вы можете передать ее в качестве третьего аргумента в метод $.get() :

Определяем тип данных ответа

Обычно, серверная сторона передает данные в одном из нескольких типовых форматов, включая XML, JSON, JavaScript, или HTML. По умолчанию jQuery пытается определить наиболее подходящий формат и разобрать данные соответствующим образом. Но лучше явно определить формат.

Для указания формата надо передать четвертый аргумент методу $.get() . Данный аргумент может быть строкой из следующего списка:


Например, если вы знаете, что скрипт сервера возвращает данные в формате JSON, то вызываете метод $.get() следующим образом:

Пример использования метода $.get()

Здесь приводится пример создания запроса AJAX с помощью метода $.get() и простая обработка ответа. Для работы примера нужно на сервере создать простой текстовый файл с именем getForecast.txt , содержащий следующий текст:

Данный файл будет имитировать ответ в формате JSON, который мог быть сформирован скриптом прогноза погоды на сервере.

Затем создаем страницу showForecast.html в той же папке что и getForecast.txt :

Открываем showForecast.html в браузере и нажимаем кнопку «Получить прогноз погоды». В окне сообщения получим прогноз погоды с нашего сервера.

Вот как работает данный код:

  1. showForecast.html содержит элемент button «Получить прогноз погоды» с ID getForecast .
  2. JavaScript вверху страницы выполняется как только страница будет загружена и DOM окажется в состоянии готовности.
  3. Код JavaScript сначала привязывает обработчик события click к кнопке #getForecast . Данный обработчик выполняет AJAX запрос GET к getForecast.txt , передавая название города и дату для прогноза. Также определяется возвратная функция success(), которая будет выполняться по завершению запроса. Формат возвращаемых сервером данных определяется как JSON.
  4. Файл getForecast.txt возвращает браузеру данные прогноза в формате JSON.
  5. Вызывается функция success() . jQuery разбирает данные JSON, полученные от getForecast.txt , конвертирует их в объект JavaScript, и передает их в функцию.
  6. Функция возвращает объект данных forecastData и выводит сообщение, которое содержит несколько свойств объекта, включая название города, прогноз и температуру.

Простой пример в несколько строк демонстрирует работу запроса AJAX с использованием метода $.get() .

Данный урок подготовлен для вас командой сайта ruseller.com
Источник урока: www.elated.com/articles/ajax-with-jquery-a-beginners-guide/
Перевел: Сергей Фастунов
Урок создан: 5 Марта 2012
Просмотров: 162882
Правила перепечатки

5 последних уроков рубрики «jQuery»

Анимация набора текста на jQuery

Сегодня мы бы хотели вам рассказать о библиотеке TypeIt — бесплатном jQuery плагине. С её помощью можно имитировать набор текста. Если всё настроить правильно, то можно добиться очень реалистичного эффекта.

Временная шкала на jQuery

jQuery плагин для создания временной шкалы.

Заметка: Перезагрузка и редирект на JavaScript

Быстрая заметка, где вы сможете найти парочку JS сниппетов для перезагрузки и перенаправления пользователей через JavaScript.

Рисуем диаграмму Ганта

jQuery плагин для создания диаграммы Ганта.

AJAX и PHP: загрузка файла

Пример того как осуществить загрузку файла через PHP и jQuery ajax.

JavaScript — Синхронный AJAX запрос (XMLHttpRequest)

Урок, в котором на простых примерах разберем, как работать с технологией AJAX, а именно познакомимся с тем как с помощью объекта XMLHttpRequest (сокращённо XHR) создавать синхронные HTTP-запросы к серверу и получать от него ответы.

Основы AJAX

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

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

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

  1. Получение некоторой информации (данных) со страницы или формы (при необходимости)
  2. Отправление запрос на веб-сервер
  3. Получение ответа с веб-сервера
  4. Отображение результатов на странице, если ответ был успешен.

Основы создания синхронных AJAX запросов

Пример 1. Выполнение синхронного AJAX запроса

Рассмотрим пример выполнения синхронного AJAX запроса к серверу с помощью метода XMLHttpRequest. В данном примере запросим данные, находящиеся в файле data.txt на сервере и отобразим их на странице в элементе span .

Пример будет состоять из файлов index.html , script.js и data.txt , которые для простоты можно расположить на сервере в одном каталоге.

Начнём разработку с создания HTML-страницы, к которой подключим файл script.js . Этот файл, а точнее его содержимое будет выполнять всю основную работу. Но перед тем как перейти к его разработке, создадим на станице элементы div и span . Элемент div будет играть роль кнопки, при нажатии на которую будет выполняться AJAX запрос. А элемент span будет играть роль контейнера, который будет содержать ответ, пришедший с сервера.

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

После этого откроем файл data.txt и введём в него текст «Привет, мир!». Сохраним и закроем файл.

И наконец, перейдём к созданию файла script.js . Содержимое этого файла будет выполнять все основные действия, т.е. отправлять ajax запрос на сервер, принимать от сервера ответ и обновлять содержимое страницы (помещать ответ в элемент span ).

Рассмотрим создание данного файла поэтапно:

Получим элемент на событие click которого необходимо подписаться.

Подпишемся на событие click элемента с помощью метода addEventListener .

Создадим переменную request , которая будет содержать экземпляр объекта XMLHttpRequest .

Настроим HTTP-запрос к серверу с помощью метода open. Данный метод имеет 3 основных параметра. 1 параметр отвечает за метод, с помощью которого мы отправляем данные на сервер. Различают два основных метода: GET и POST. Метод GET передаёт данные в составе URL после знака ? (для отделения данных используется амперсанд & ).

Метод POST передаёт данные в теле HTTP-запроса.

2 параметр отвечает за адрес (URL), по которому посылается запрос. А 3 параметр определяет тип запроса: синхронный ( false ) или асинхронный ( true ).

Отправляем ajax запрос на сервер.

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

status (статус запроса). Если значение свойства равно 200, то запрос выполнен успешно. Если в status хранится другое число, значит, запрос завершился с ошибкой (например, 404, 500 и т.д.)

responseText – содержит текст ответа, который пришёл от сервера. Т.е. данное свойство всегда содержит то, что нам нужно, если статус ответа был 200.

Посмотреть на этот объект можно, например, в консоли, для этого после отправки ajax запроса на сервер достаточно поместить в код следующую строчку:

Просмотр объекта XMLHttpRequest в консоли браузера

Получаем результат и отображаем его на странице.

Пример 2. Обработка синхронного AJAX запроса на сервере с помощью PHP

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

В данном примере страница будет состоять из 3 кнопок. Первая кнопка будет иметь текст 1, вторая кнопка текст 2 и третья кнопка текст 3. При нажатии на любую из кнопок будет выполняться синхронный запрос на сервер. В качестве метода передачи запроса будем использовать GET. А адрес, по которому будем посылать запрос и параметры ajax.php . Получать данные отправленные клиентом на сервере будем с помощью GET-переменной HTTP ($_GET). После этого полученные данные будем обрабатывать на сервере, и возвращать клиенту ответ (строку).

Пример 3. Передача синхронного AJAX запроса на сервер с помощью метода POST

В этом примере данные на сервер будем передавать с помощью метода POST (в теле HTTP-запроса). В методе POST данные (параметры) передаются не в составе URL (метод GET), а в теле, которое мы посылаем серверу через send() . Т.е. для того чтобы передать данные с помощью POST, мы их должны поместить в качестве параметра методу send() . Кроме того, при отправке данных с помощью POST необходимо также указать заголовок Content-Type, содержащий кодировку с помощью которой мы зашифровали данные. Это необходимо сделать для того чтобы сервер знал как обработать (расшифровать), пришедшие к нему данные (запрос).

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

Задача

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

Средства

Frontend (клиентская часть) – библиотека jQuery версии 1.1.4 и плагин к ней ajaxUpload;

Backend (серверная часть) – Apache (любой версии), PHP 5.2.3, MySQL. В PHP 5.2.0 появились встроенные средства для работы с данными в формате JSON, которые используются в этом примере, если на вашем хостинге установлена более старая версия PHP, то эти функции придется написать самостоятельно.

Решение

Блок-схема работы скрипта изображена на рисунке (большая картинка по клику). Пунктиром обозначен момент обмена данными между клиентом и сервером.

Теперь та же логика, только словами:

1. Сначала пользователь заполняет форму и жмет кнопку «Отправить», затем клиентский скрипт (frontend) передает серверному (backend) текст из формы (передается только текст, без файла, логика простая – зачем передавать файл, если уже в тексте может быть ошибка?).

2. Серверный скрипт проверяет текст на наличие ошибок и возвращает результат клиентскому скрипту (в этом случае в формате html).

3. Клиентский скрипт обрабатывает ответ от сервера, если в ответе передана ошибка, то выводится соответствующее сообщение и скрипт завершает работу, если ошибок нет, то клиентский скрипт отдает серверному файл, выбранный пользователем.

4. Серверный скрипт проверяет корректность файла (размер, тип и т.п.) и отдает ответ клиентскому скрипту (на этот раз в формате JSON).

5. Клиентский скрипт обрабатывает полученный ответ и выводит на экран соответствующий результат.

Исходники и комментарии

В конце статьи будут даны ссылки на полные исходные коды всех файлов. Ниже приведены комментарии к самым важным участкам кода.

Форма запроса (html, файл add.php)

В тэгах head подключаем библиотеку jQuery, плагин ajaxUpload и файл с нашим frontend’ом:

Далее рисуем форму, для отправки текста и файла:

M1 и m2 – это два текстовых поля, данные из которых будут записаны в БД на сервере, img – поле для выбора закачиваемого файла, в данном примере рассмотен вариант с закачкой картинки.

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

Далее рисуем два слоя, в одном будет выводиться сообщение вида «Подождите идет загрузка», во втором – все остальные сообщения, в том числе и сообщение об успешном завершении работы скрипта:

Картинка loading.gif должна лежать в той же папке, что и текущий файл (или пропишите в тэге img соответствующий путь).

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

Frontend (Javascript, файл scriptik.js)

Здесь описаны только функции из файла scriptik.js , отвечающие за передачу/прием данных от сервера, остальные функции носят чисто украшательский характер и их описание выходит за рамки этой статьи.

Передаем backend файлу insert.php данные из текстовых полей:

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

То есть, если мы получили отрицательный результат, то выводим сообщение об ошибке, если получили положительный результат, то приступаем к закачке файла на сервер. Imageupload.php – backend, отвечающий за закачку файла и его соответствие некоторым требованиям. Скрипту imageupload.php методом GET передается id, под которым на сервере был сохранен переданный текст, чтобы с тем же id сохранить и файл.

Опять обрабатываем ответ сервера, теперь уже ответ приходит в формате JSON , по этому к переменным, пришедшим в ответе можно получить доступ используя объект вида result.var1, result.var2 и т.д.

img_upload – это объект, в котором сохраняется результат. Сервер передает клиенту две переменные: img_upload.result – информация о том закачалась картинка или нет, img_upload.name – имя, под которым картинка сохранена на сервере.

Backend (PHP, файлы insert.php и imageupload.php)

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

insert.php – проверка на корректность, запись в БД переданного клиентом текста и передача ответа клиенту.

Для безопасности проверяем пришел запрос через XMLHttpRequest или нет:

Пишем данные в базу и отдаем ответ клиенту:

imageupload.php – проверка на корректность закачанного файла, копирование файла в нужную папку и передача ответа клиенту.

Вот собственно и все. Готов ответить на любые вопросы.

Веб-разработка

В настоящее время, каждый, даже самый захудалый сайт, старается обеспечить взаимодействие с пользователем. Гостевые книги, комментарии под статьями, опросы, голосования и прочее — все это требует передачи информации от пользователя к серверу. Как именно это происходит? Эта статья о методах передачи данных GET и POST.

Чаще всего, для передачи данных, используются. ссылки! Да-да! Когда вы нажимаете на ссылку, часто, вы передаете данные сервер. Большинство современных веб-сайтов, активно эксплуатируют этот метод передачи информации. Этот метод называется GET. Когда мы нажимаем на ссылку, мы хотим получить (to get) какой-то документ с сервера. Поэтому метод передачи данных через ссылку и назвали get.

Метод GET.

Метод GET удобен тем, что прост в эксплуатации. Но у него есть недостатки. Во-первых, методом GET нельзя передавать большие объемы информации, потому что данные, передаваемые этим методом входят в соств URL, длина которого ограничена.

Пример: ссылка http://dayte2.com/?u=shaman&act=state&num=9 содержит данные, передаваемые методом GET. Эти данные идут после знака вопроса.

Так как данные, передаваемые методом GET входят в соства URL документа, их может подсмотреть любой желающий. У этого есть преимущества и недостатки. Преимущество состоит в том, что можно послать ссылку вместе с данными другу. Недостаток в том, что в строке браузера отображается и ваш, только что введенный пароль. Это одна из причин, почему данные, представляющие ценность, всегда нужно передавать методом POST.

Метод POST.

Как и метод GET, метод POST служит для передачи данных на сервер. Однако, данные, переданные таким образом, идут не в URL документа, а в теле запроса, после заголовков. Эти данные могут быть восприняты CGI-программой.

Когда данные отправляются методом POST, серверу приходит что-то вроде:

POST lines.pl HTTP/1.1
Accept: */*
Referer: http://dayte2.com/shaman.shtml
Accept-Language: ru
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Host: dayte2.com
Content-Length: 106
Connection: Keep-Alive
Cache-Control: no-cache

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

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

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

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

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

Есть так же, методы, основанные на cookie или серверных сессиях, но это — тема отдельной статьи.

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

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

Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL