ПРОДВИНУТЫЕ ЗАПРОСЫ И ОТВЕТЫ В AJAX
ADO в Delphi AJAX Android C++ CakePHP CMS COM CSS Delphi Flash Flex HTML Internet Java JavaScript MySQL PHP RIA SCORM Silverlight SQL UML XML Бази даних Веб-розробка Генетичні алгоритми ГІС Гітара Дизайн Економіка Інтелектуальні СДН Колір Масаж Математика Медицина Музика Нечітка логіка ООП Патерни Подання знань Розкрутка сайту, SEO САПР Сесії в PHP Системне програмування Системний аналіз Тестологія Тестування ПЗ Фреймворки Штучний інтелект
|
УСОВЕРШЕНСТВОВАННЫЕ ЗАПРОСЫ И ОТВЕТЫ В AJAX
В совершенстве изучите коды состояния HTTP, состояния готовности и объект XMLHttpRequest
Подробно о состояниях готовности HTTP Вы должны помнить из предыдущей статьи, что объект XMLHttpRequest имеет свойство readyState. Это свойство удостоверяет, что сервер завершил запрос, и обычно функция обратного вызова использует данные от сервера для обновления Web-формы или страницы. В листинге 1 приведен простой пример этого.
Это определенно наиболее общее (и наиболее простое) использование состояний готовности. Как вы, возможно, догадались по числу "4", существует и несколько других состояний готовности:
Если вы хотите выйти за рамки основ Ajax-программирования, то должны знать не только эти состояния, но и когда они возникают, а также как вы можете использовать их. Первое и самое главное – вы должны изучить, на каком этапе запроса возникает каждое состояние. К сожалению, это не такая уж интуитивная вещь, и имеются специальные случаи.
Скрытые значения состояний готовности Первое состояние готовности, обозначаемое
значением свойства Тем не менее, в интересах полноты изложения взгляните на листинг 2, в котором показано, как получить состояние готовности, когда оно установлено в 0.
В этом простом примере
Очевидно, это не очень хорошо; существует
очень мало случаев, когда вы должны проверять, что
Обзор состояния готовности выполняющегося запроса От состояния готовности 0 ваш объект запроса
должен проходить через каждое другое состояние в обычном запросе и ответе, и, в
конце концов, закончить на состоянии 4. Вот почему вы видите строку кода Увидеть этот процесс во время его протекания является тривиальной задачей. Вместо выполняющегося только при состоянии готовности равном 4 кода в вашей функции обратного вызова просто выводите состояние готовности каждый раз при вызове функции. Пример приведен в листинге 3.
Вы должны создать функцию для вызова из вашей
Web-страницы и передать в ней запрос серверному компоненту (просто такая же
функция, как и приведенная в листинге 2, а также в примерах первой и второй
статей данного цикла статей). Убедитесь в том, что при настройке вашего запроса
вы установили функцию обратного вызова в Этот код является отличной иллюстрацией того,
что на самом деле означает
Попробуйте этот код самостоятельно. Поместите его на вашу Web-страницу и активизируйте ваш обработчик событий (нажмите кнопку, выйдите из поля или используйте любой метод, который вы установили для инициирования запроса). Ваша функция обратного вызова выполнится несколько раз (каждый раз при изменении состояния готовности запроса), и вы увидите предупреждение для каждого состояния. Это наилучший способ следовать за запросом через каждое его состояние.
Получив общее понятие об этом процессе, попробуйте обратиться к вашей Web-странице из нескольких различных браузеров. Вы должны заметить некоторую несовместимость в том, как обрабатываются эти состояния готовности. Например, в Firefox 1.5 вы увидите следующие состояния готовности:
Это не должно быть сюрпризом, поскольку здесь представлено каждое состояние запроса. Однако если вы обратитесь к этому же приложению в Safari, вы должны увидеть (или скорее, не увидеть) кое-что интересное. Вот состояния в Safari 2.0.1:
Safari на самом деле пропускает первое состояние, и нет здравого объяснения, почему; просто Safari работает таким образом. Это также выявляет важный момент: в то время как использование значения состояния запроса равное 4 перед использованием данных от сервера является неплохой идеей, написание кода, зависящего от каждого промежуточного состояния готовности, несомненно, путь к получению различных результатов в различных браузерах. Например, при использовании Opera 8.5, отображение состояний готовности становится даже еще хуже:
И последнее, но важное - Internet Explorer отображает следующие состояния:
Если с запросом имеются проблемы, это самое первое место, где следует их искать. Добавьте вывод предупреждения, чтобы увидеть состояние готовности запроса и убедиться в том, что все работает нормально. Еще лучше - протестируйте и в Internet Explorer, и в Firefox – вы получите все четыре состояния готовности и сможете проверить каждый этап запроса. Теперь посмотрим со стороны ответа.
Разобравшись с различными состояниями готовности,
происходящими во время запроса, вы готовы исследовать другую важную часть
объекта
Листинг 1 довольно прост. Листинг 4 немного
более сложен, но в начале оба проверяют состояние готовности и затем извлекают
значение (или значения) из свойства
Просмотр текстового ответа во время запроса Аналогично состоянию готовности значение
свойства
Теперь откройте ваше Web-приложение в браузере
и активируйте запрос. Для получения наибольшей информации из этого кода
используйте либо Firefox, либо Internet Explorer, поскольку оба обрабатывают
все возможные состояния готовности во время запроса. Например, когда состояние
готовности равно 2, свойство
А при состоянии готовности 3 сервер поместил
значение в свойство
Вы увидите, что ваши ответы при состоянии готовности 3 отличаются от сценария к сценарию, от сервера к серверу и от браузера к браузеру. Но все же этот подход продолжает оставаться чрезвычайно полезным при отладке вашего приложения.
Во всей документации и спецификациях
утверждается, что только при состоянии готовности 4 данные можно использовать
безопасно. Поверьте мне, вы редко найдете случаи, когда данные не могут быть
получены из свойства Лучшей идеей является предоставление
некоторого рода обратной связи с пользователем – когда состояние готовности
равно 3, отобразить, что ответ на подходе. В то время, как использование такой
функции как Естественно, такой подход понятнее, но зависит от используемого браузера. В Opera вы никогда не получите первых двух состояний готовности, а Safari пропустит 1. По этой причине я оставляю этот пример как упражнение и не включаю в эту статью. Время взглянуть на коды состояния.
Пристальный взгляд на коды состояния HTTP Имея в багаже знаний ваш опыт Ajax-программирования состояния готовности и ответа сервера, вы готовы добавить еще один уровень усовершенствования Ajax-приложений – работу с кодами состояния HTTP. Эти коды не являются чем-то новым для Ajax. Они существуют в Web со времен его появления. Вы, вероятно, уже видели некоторые из них в вашем браузере
Можно найти еще. Для добавления еще одного уровня управляемости и оперативности (и особенно более надежной обработки ошибок) к вашим Ajax-приложениям необходимо проверять коды состояния в запросе и ответе соответственно.
Во многих Ajax-приложениях вы увидите функцию обратного вызова, проверяющую состояние готовности и продолжающую работу с данными ответа сервера, как в листинге 6.
Это недальновидный и подверженный ошибкам подход к Ajax-программированию. Если сценарий требует аутентификации, а ваш запрос не предоставляет корректных данных, сервер возвратит код ошибки 403 или 401. Однако состояние готовности будет установлено в 4, поскольку сервер ответил на запрос (даже если ответ на ваш запрос не такой, какой вы хотели или ожидали). В результате пользователь не получит правильных данных и может даже получить неприятную ошибку, когда ваш JavaScript-код попытается использовать несуществующие серверные данные. Гарантировать то, что сервер не только
завершил обработку запроса, но и возвратил код состояния "Все в
порядке", требует минимальных усилий. Этот код равен "200" и
возвращается в свойстве
С этими небольшим числом дополнительных строк кода вы можете быть уверены, что если что-то пойдет не так, ваши пользователи получат (под вопросом) полезное сообщение об ошибке вместо страницы с искаженными данными без всяких объяснений.
Переадресация и перенаправление Перед детальным рассмотрением ошибок имеет смысл поговорить о том, о чем вы, возможно, не должны беспокоиться при использовании Ajax – переадресации. В кодах состояния HTTP есть семейство кодов состояния 300, включающих:
Ajax-программисты, возможно, не беспокоятся о переадресации по двум причинам:
В результате ваши запросы не могут быть переадресованы на другой сервер без генерирования ошибки защиты. В этих случаях вы вовсе не получите код состояния. Вы просто получите ошибку JavaScript в консоли отладки. Поэтому, думая о многообразии кодов состояния, вы можете почти совершенно игнорировать коды переадресации.
Как только вы позаботились о коде состояния 200 и поняли, что можете в значительной степени проигнорировать 300-е семейство кодов состояния, единственной группой кодов, о которой надо подумать – это 400-е семейство, указывающее на ошибки различного типа. Повторно взгляните на листинг 7 и обратите внимание, что хотя ошибки и обрабатываются, пользователю выдается очень общее сообщение об ошибке. И хотя это шаг в правильном направлении, это сообщение все еще остается бесполезным с точки зрения информирования пользователя или программиста, работающего с приложением, о том, что произошло. Прежде всего, добавьте поддержку отсутствующих страниц. Они действительно не должны часто появляться в реальных системах, но это нередко случается при тестировании перемещенного сценария или при вводе программистом неверного URL. Если вы можете изящно обрабатывать ошибки 404, то намного лучше поможете поставленным в тупик пользователям и программистам. Например, если сценарий был удален с сервера, а вы используете приведенный в листинге 7 код, вы должны увидеть ничего не объясняющее сообщение об ошибке, показанное на рисунке 5.
Пользователь не может узнать, в чем заключается проблема: в аутентификации, отсутствующем сценарии (как в данном случае), ошибке пользователя, или ошибке в исходном коде. Небольшие дополнения к коду могут сделать это сообщение об ошибке намного более точным. Посмотрите на листинг 8, который обрабатывает отсутствие сценария и ошибки аутентификации.
Это все довольно просто, но действительно предоставляется дополнительная информация. На рисунке 6 показана эта же ошибка, что и на рисунке 5, но в данном случае код обработки ошибок выдает пользователю или программисту лучшую картину того, что случилось.
В ваших собственных приложениях вы можете предусмотреть очистку имени пользователя и пароля при неудачной аутентификации и добавить сообщение об ошибке на экран. Аналогичный подход можно применить при более изящной обработке отсутствующих сценариев или других ошибок 400-го семейства (таких как 405 для неподдерживаемого метода запроса, например, HEAD-запроса, или 407 при требовании прокси-аутентификации). Какой бы вы вариант не выбрали, он начинается с обработки кода состояния, полученного от сервера.
Если вы действительно хотите управлять
объектом
В действительности выполнение HEAD-запроса
является довольно тривиальной задачей; вы просто вызываете метод
При выполнении подобного HEAD-запроса сервер не возвращает реальный ответ, как для GET или POST-запросов. Вместо этого сервер должен только возвратить заголовки ресурса, в которые включается последнее время модификации содержимого запроса, месторасположение запрашиваемого ресурса и довольно много другой интересной информации. Вы можете использовать эту информацию о ресурсе еще до того, как сервер должен будет обработать и возвратить этот ресурс. Самой простой вещью, которую вы можете сделать с подобным запросом, является выдача всех заголовков ответа. Это даст вам представление о том, что доступно вам через HEAD-запросы. В листинге 10 приведена простая функция обратного вызова, которая отображает все заголовки ответа из HEAD-запроса.
На рисунке 7 показаны заголовки ответа из простого Ajax-приложения, выполняющего HEAD-запрос на сервер.
Вы можете использовать любой из этих заголовков (от типа сервера до типа содержимого) индивидуально для получения дополнительной информации или функциональности в Ajax-приложении.
Вы увидели, как проверить ошибку 404 при отсутствии URL. Если это превращается в общую проблему (возможно, определенный сценарий или сервлет в данный момент времени находитcя в режиме offline) – вы, вероятно, захотите проверить URL перед выполнением полного GET или POST-запроса. Для этого выполните HEAD-запрос и проверьте 404-ю ошибку в вашей функции обратного вызова; в листинге 11 приведен пример такой функции.
По правде говоря, это имеет небольшое значение. Сервер должен ответить на запрос и обработать его для заполнения значения длины содержимого заголовка ответа, поэтому вы не экономите время обработки. Кроме того, выполнение запроса и определение существования URL при помощи HEAD-запроса занимает столько же времени, сколько и выполнение GET или POST-запроса и последующая обработка ошибок (как показано в листинге 7. Хотя иногда может быть полезно знать точно, что доступно; вы никогда не знаете, когда вас пробьет на творчество и вам понадобится HEAD-запрос!
Одной из ситуаций, когда HEAD-запрос может оказаться полезным, является необходимость узнать длину содержимого, или даже его тип. Это позволяет определить, будет ли возвращен процессу большой объем данных, или сервер будет пытаться возвратить двоичные файлы вместо HTML, текстовых данных или XML (которые намного проще обработать в JavaScript, чем двоичные данные). В таких случаях вы просто используете
соответствующее имя заголовка и передаете его в метод Во многих приложениях выполнение HEAD-запросов не добавляет функциональности и может даже замедлить запрос (путем передачи HEAD-запроса для получения информации об ответе и последующий GET или POST-запрос для реального получения данных). Однако если вы не уверены в сценарии или серверном компоненте, HEAD-запрос может помочь вам получить некоторые основные данные без работы с данными ответа или без снижения пропускной способности для передачи этого ответа. Зверніть увагу на додаткові посиланняЯкщо вас цікавить...Головний розділзагрузка...
|
Сторінки, близькі за змістом
|
Copyright © 2008—2024 Портал Знань.
При використанні матеріалів посилання, для інтернет-ресурсів — гіперпосилання, на Znannya.org обов'язкове.
Зв'язок
|
НТУУ "КПІ" Інженерія програмного забезпечення КПІ Лабораторія СЕТ |
|