|
|
|||||||||||||||||||||||||||||
|
Сверхдинамичные веб-интерфейсы (документация)Источник: articles
Одно из главных затруднений, с которым сталкиваются разработчики интерфейсов веб-приложений, состоит в том, что после того, как страница оказалась в браузере клиента, связь браузера с сервером заканчивается. Любое действие с элементом интерфейса требует повторного обращения к серверу с повторной загрузкой новой страницы. Из-за этого веб-приложение теряет свою элегантность и медленно работает. В данной статье я расскажу о том, как данную проблему можно решить с помощью javascript и объекта xmlhttprequest. Я уверен, что вам знакома традиционная модель интерфейса веб-приложений. Пользователь запрашивает страницу с сервера, которая на сервере создается, а затем пересылается браузеру. У данной страницы есть html-элементы, описывающие форму, в которую пользователь вводит данные. После этого пользователь отсылает данные на сервер и получает новую страницу, основанную на введенных данных, и процесс повторяется. Весь этот процесс определяется самой природой http-протокола и отличается от того, как мы работаем с обычными приложениями, интерфейс которых неразрывно связан с программной логикой. Возьмем простой пример ввода серийного номера в каком-либо windows-приложении. Согласно правилам, после того, как вы закончите вводить замысловатый набор цифр и букв в поля, рядом с ними появится зеленая "галочка", означающая, что вы ввели правильный номер. Она появляется моментально, как результат логики "вшитой" в интерфейс. Как только вы закончили набирать номер, программа проверяет его и выдает ответ. В веб-интерфейсе это стандартное поведение выглядит совершенно по-другому. Разумеется, поля, в которые вы вводите серийный номер выглядят точно так же, но по завершении ввода, пользователю надо, нажав кнопку, отправить страницу на сервер, который проверит введенные данные. Обратно пользователю вернется новая страница, где будет выведено сообщение о правильном или неправильном серийном номере. Пользователю в случае неудачи надо вернуться на предыдущую страницу и снова повторить попытку. И так до бесконечности. Разумеется не часто веб-приложение требует от пользователя ввести серийный номер, но есть бесчисленное множество других примеров, где быстрая реакция интерфейса на действия пользователя очень бы пригодилась. А так как вся программная логика находится на сервере, получить такой результат в традиционном веб-приложении весьма сложно. Благодаря javascript определенное количество программной логики можно перенести в html-страницу, что позволит быстро реагировать на действия пользователя. Однако у этого решения есть один главный недостаток. Первая проблема заключается в том, что как только javascript попадает в браузер пользователя вместе со страницей, программная логика доступна для просмотра невооруженным глазом. В случае например с проверкой правильности введенного адреса e-mail это может быть и не страшно, но если проверка связана с серийным номером, алгоритм проверки становится доступным всем, кто скачал страницу, а это неприемлемо. Вторая проблема заключается в том, что серьезную программную логику в страницу поместить невозможно, так как интерфейс просто не предназначен для этого. Вся логика должна находиться на уровне приложения, а не пользовательского интерфейса, а это значит - мы опять возвращаемся на сервер. Проблема дополняется еще тем, что не всегда с уверенностью можно ожидать наличия javascript в браузере клиента. В то время, как большинство пользователей оставляют поддержку javascript в своих браузерах включенной, существует значительное количество пользователей, которые этого не делают, или пользуются таким браузером, где javascript отсутствует или вообще не нужен как класс. Следовательно всю логику, которую делает javascript на стороне клиента, все равно придется проверять на сервере на всякий случай. Решением этой проблемы может стать объект xmlhttprequest. Этот объект впервые был реализован компанией microsoft в виде объекта activex, но сейчас он доступен как встроенный объект во всех браузерах mozilla и safari. Этот объект позволяет javascript-у осуществлять http-запросы к удаленному серверу без необходимости перезагружать страницу. По сути http-запросы отправляются и получаются полностью за "кулисами" страницы, а пользователь их даже не замечает. Это огромный шаг вперед, так как позволяет разработчику веб-приложения достичь той самой желанной цели - создание быстрого пользовательского интерфейса с сохранением при этом программной логики на сервере. С помощью javascript-а данные, введенные пользователем, отправляются на сервер, там они обрабатываются и пользователь практически тут же получает ответ на введенные данные. Из-за своей противоречивой истории объект xmlhttprequest еще не является частью какого-либо стандарта (хотя нечто подобное уже было предложено в спецификации w3c dom level 3 load and save). Поэтому существует два отличных друг от друга метода вызова этого объекта в коде скрипта. В internet explorer объект activex вызывается так: В mozilla и safari это делается проще (так как там это объект, встроенный в javascript): Разумеется из-за таких различий вам необходимо создавать в коде ветки, каждая из которых будет выполняться в зависимости от того, в каком браузере загружен скрипт. Существует несколько способов, как сделать это (включая различные мудрёные хаки и метод "условных комментариев"). Но я считаю, что лучше всего просто проверять в коде, поддерживается ли браузером тот или иной объект. Хорошим примером может служить код, взятый с сайта apple, где выложена документация по этому объекту. Давайте им и будем пользоваться: function loadxmldoc(url) { В этом коде особенно важно обратить внимание на свойство onreadystatechange. Посмотрите, как ему присваивается значение функции processreqchange. Это свойство - хендлер события, которое запускается всякий раз, когда меняется состояние объекта req. Состояния обозначаются номерами с 0 (объект неинициализирован) по 4 (запрос выполнен). Важно это потому, что наш скрипт не будет ждать ответа от сервера, чтобы продолжить свою работу. http-запрос будет сформирован и отослан на сервер, но скрипт будет выполняться дальше. Из-за того, что мы выбрали такой вариант поведения, нам нельзя просто в конце функции вернуть результат запроса, так как нам неизвестно, получили мы его к этому времени или нет. Для этого мы и предусмотрели функцию processreqchange, которая будет отслеживать состояние объекта req, и сообщит нам в нужное время, что процесс получения документа закончен, и мы можем идти дальше. Для этого функции processreqchange требуется проверять две вещи. Первая - ждать, когда состояние объекта req изменится на 4 (означающее, что процесс получения документа с сервера закончен). Второе, это проверить http-статус ответа. Вы знаете, что код 404 означает "файл не найден" и 500 - "произошла ошибка на сервере". Но нам нужен старый добрый код 200 ("все ОК"), который означает, что на сервере наш запрос был успешно выполнен. Если мы получили и состояние 4 и код 200, мы можем продолжать выполнение нашего скрипта и обрабатывать результаты, полученные от сервера. Разумеется в противном случае мы должны обработать все ошибки, например, если код ответа отличается от 200. Я собираюсь создать работающий пример для демонстрации вышеизложенных идей. Во многих веб-приложениях есть процедура, когда новый пользователь регистрируется на сервере и требуется выбрать "ник" для регистрации. Очень часто этот "ник" должен быть уникальным, и потому после того, как пользователь выбрал себе "ник", на сервере осуществляется проверка по базе данных пользователей, есть уже такой "ник" или нет. Если вы когда-либо регистрировались на каком-нибудь почтовом веб-сервере, вы помните, как утомительно подыскивать "ник", которым еще никто не пользуется. Было бы очень хорошо, если бы проверка осуществлялась без необходимости всякий раз обновлять страницу. Для решения мы воспользуемся четырьмя ключевыми элементами: xhtml-формой, функцией javascript, специально написанной для данной ситуации, двумя нашими общими функциями, о которых мы говорили выше, и наконец серверным скриптом, который будет обращаться к базе данных. Это самая легкая часть работы - простая форма с полем для ввода "ника". К событию onblur мы привязываем наш скрипт проверки. Для того, чтобы вывести пользователю сообщение о результатах проверки, я вставил его в форму и спрятал с помощью css. Это более элегантный и вежливый способ, чем стандартное диалоговое окно функции alert(). this name is in use, please try another. В css объявлены свойства класса hidden, а также еще одного класса error, который служит для вывода сообщений об ошибке. span.error{ Функция checkname служит для проверки данных, введенных пользователем форму. Задача функции - взять данные, решить, какому серверному скрипту эти данные отдать, вызвать другую функцию, которая сделает всю "грязную" работу с http-запросами и ответами, и затем обработать ответ. Эта наша функция будет состоять из двух частей. Одна часть - берет данные из формы, а другая - обрабатывает ответ от сервера. Я объясню, зачем это сделано, чуть позднее. } Ответ обрабатывается просто - ответ, который мы получим от серверного скрипта, будет либо 1, либо 0. 1 означает, что такой "ник" уже кем-то используется. В зависимости от ответа наша функция меняет название класса сообщения об ошибке - оно либо показывается, либо прячется. Как понятно из кода, работу на сервере выполняет скрипт checkusername.php. Как вы видели выше, работа с http выполняется двумя функциями: loadxmldoc и processreqchange. В первом практически ничего менять не надо, а во втором требуется кое-что поменять для работы с dom-ом. Как вы помните, пока успешный результат выполнения запроса не будет передан функции processreqchange, мы не можем из этой функции вернуть какое-либо значение. Из-за этого нам требуется выполнять явный вызов функции из другого места кода, чтобы воспользоваться результатом. Вот почему функция checkname разбита на две части. Таким образом, главная задача функции processreqchange состоит в том, чтобы обработать xml-ответ, полученный от сервера, и передать определенное значение из этого ответа функции checkname. Мы не хотим вносить в эти функции какой-либо специфический код, так как эти функции могут использоваться и другими элементами страницы для обращения к серверу. Поэтому мы и не вписывали в функцию processreqchange имя функции checkname. Вместо этого мы решили, что сервер сам будет в своем ответе давать название функции, которая к нему обращалась. checkname Разбор этого простого ответа выполняется без каких-либо проблем. method = response.getelementsbytagname('method') \\ result = response.getelementsbytagname('result') \\ eval(method + '(\'\', result)'); Обратившись к свойству responsexml объекта xmlhttprequest, мы получаем xml-ответ, пришедший от сервера, который мы затем разбираем с помощью dom. Взяв из ответа название функции, которая требовала этот ответ, мы знаем, какой функции надо передать полученное значение. После того, как вы закончите тестирование, уберите условие else, чтобы скрипт не беспокоил пользователей лишним сообщением об ошибке. Последний элемент нашей мозаики - это серверный скрипт, который будет получать запрос, обрабатывать его и возвращать ответ в виде xml. В нашем примере скрипт будет обращаться к базе данных пользователей, чтобы определить, используется ли уже данный "ник" или нет. Для краткости в моем примере скрипт не использует базу данных, а просто проверяет два имени "drew" и "fred". '; ?> checkname Разумеется, ту же процедуру проверки надо предусмотреть и в том серверном скрипте, который будет выполняться, когда пользователь нажмет кнопку "submit" на форме регистрации. Это на тот случай, если у него в браузере был отключен javascript, или пользователь намеренно ввел "ник", который уже используется. Кроме того на загруженных сайтах может так случиться, что во время выбора "ника" он был свободен, а на момент подачи его уже кто-то занял. В качестве следующего шага расширьте сами функциональность скрипта. Например сервер может возвращать варианты альтернативных "ников" на основе "ника", выбранного пользователем, но уже занятого.
|
|