В предыдущем примере была рассмотрена возможность проверки пра¬вильности заполнения каждого поля в форме. Другая популярная фор¬ма шаблона проектирования регулируемой передачи данных основана ва периодической проверке содержимого единственного поля по мере его изменения. Эта версия шаблона проектирования с успехом применя¬ется в веб-приложениях Bitflux LiveSearch и Google Suggest, в которых данные отправляются серверу периодически, по мере их ввода. В обоих случаях передача данных вызывает исполнение операции поиска на сервере, однако тот же самый метод может применяться для проверки правильности заполнения поля по мере ввода в него новых символов.
Предположим, что веб-приложение потребует, чтобы вы сначала вы¬брали имя пользователя (скажем, как первый шаг в многошаговом процессе регистрации) и только после этого вводили данные в форму. Вы наверняка захотите убедиться, что введено уникальное имя поль¬зователя. Приложение при этом может не ждать, пока будет отправле¬на, вся форма, а периодически отправлять серверу данные для провер¬ки, гарантируя тем самым, что остальные данные не будут отправлены до тех пор, пока не будет выбрано корректное имя пользователя.
Обратите внимание, что этот пример приводится только в демонстра¬ционных целях. В реальном приложении придется предусмотреть защиту от спам-ботов, которые могут задействовать эту функциональность для сбора сведений об именах пользователей и их паролях.
Форма для этого примера выглядит намного проще и состоит из един¬ственного текстового поля и кнопки «Далее»:
ctdxiabel for="txtUsernarae">HMfl пользователи<Дй> •ctdxinput type="text" id="txt(Jsernarae" name="txtUsername" />"
Обратите внимание, что сохранился общий формат представления ф мы из предыдущего примера, включая скрытое изображение, по ляющееся при обнаружении ошибки. Функция validateFieldO из п дыдущего примера претерпела некоторые изменения:
function validateField(oEvent) { oEvent = oEvent || window.event; var txtField = oEvent.target || oEvent.srcElement;
var btnNext = document.getElementById("btnNext"); btnNext.disabled = true;
if (iTimeoutld != null) {
\.:vclearTimeout(iTimeoutld); 4*i44' .
iTimeoutld = null;
if (!oXmlHttp) { '
oXmlHttp = zXmlHttp.createRequestO; } else if (oXmlHttp.readyState != 0) {
oXmlHttp.abort();
oXmlHttp. openf'get", "ValidateForm.php? " + txtField.name + "="
+ encodellRIComponent(txtField.value), true oXmlHttp.onreadystatechange = function () {
if (oXmlHttp.readyState == 4) { if (oXmlHttp.status == 200) {
var arrlnfo = oXmlHttp.responseText.split("||"); var imgError = document.getElementByldC'img"
+ txtField.id.substring(3) + "Error"
if (!eval(arrlnfo[0])) {
imgError.title = arrInfo[1];
imgError.style.display = "";
txtField.valid = false; } else {
imgError.style.display = "none"; txtField.valid = true;
}
} else {
alertCTlpn попытке соединения с сервером возникла ошибка.
}
>
};
iTimeoutld - setTimeout(function () {
oXmlHttp.send(null); .
}. 500);
>;
В первую очередь следует обратить внимание на то, что здесь появи¬лись две глобальные переменные: oXmlHttp и iTimeoutld. Первая из них, oXmlHttp, хранит ссылку на глобальный объект XMLHttp, который ис¬пользуется многократно (в противоположность предыдущему приме¬ру, где объект XMLHttp использовался один раз). Вторая, iTimeoutld, хранит идентификатор тайм-аута, задаваемого для задержки переда¬чи запроса. В начале новой части функции сразу же блокируется кноп¬ка «Далее». Это очень важно, потому что запрос не может быть отправ¬лен сразу после вызова данной функции. После этого сбрасывается тайм-аут, если в переменной iTimeoutld содержится непустая ссылка -это предотвращает отправку чрезмерного количества запросов подряд. (Если есть незавершенный запрос, он аннулируется.)
Затем проверяется, был ли создан ранее глобальный объект oXmlHttp. Если переменная oXmlHttp содержит значение null, то создается объект XMLHttp и ссылка на него записывается в эту переменную. Если объект XMLHttp уже существует, то проверяется значение его свойства readySta-te, чтобы выяснить, готов ли объект к выполнению очередного запро¬са. Из предыдущей главы известно, что обращение к методу ореп() вы¬зывает изменение значения свойства readyState с 0 на 1, таким образом, значение, отличное от 0, говорит о том, что объект XMLHttp занят обра¬боткой запроса и необходимо вызвать метод abort(), прежде чем пы¬таться выполнить новый запрос. Обратите внимание* что в этом при¬мере фигурирует тот же самый файл Validate Form. php.
Внутри обработчика события onreadystatechange появилась всего одна новая строка, которая изменяет состояние кнопки «Далее» в зависи¬мости от результатов проверки имени пользователя. В самом конце вызывается функция setTimeoutO, чтобы задержать посылку запроса на полсекунды (500 миллисекунд). Результат обращения к setTime-cut() запоминается в переменной iTimeoutld, что делает возможным от¬менить тайм-аут на следующем вызове функции. Манипулируя вре¬менными задержками таким способом, приложение будет отправлять запрос на сервер, только если пользователь в течение половины секун¬ды ничего не вводил. Если пользователь нажимает клавиши быстро, одну за другой, то тайм-аут будет все время сбрасываться, и лишь ко¬гда наступит пауза, запрос будет послан.
Осталось лишь установить обработчик события. Поскольку теперь ин¬формация отправляется в процессе ее ввода, мы не можем целиком по¬ложиться на обработчик события onchange (хотя он по-прежнему необ¬ходим). В этом случае необходимо отслеживать и обрабатывать собы¬тие onkeyup, которое возникает всякий раз, когда нажимается клавиша на клавиатуре.
window.onload = function () { if (zXmlHttp.isSupportedO) {
var btnNext = document.getElementById("btnNext");
var txtUsername = document.getElement8yId("txtUsername");
btnNext.disabled = true; txtUsername.onkeyup = validateField;
txtUsername.onchange = validateField; txtUsername.valid = false;
}
>;
Этот обработчик тоже очень напоминает обработчик из предыдущ примера. Изменились только имя кнопки (теперь она называется b Next) и назначение функции validateField() (теперь она выступает в честве обработчика события onkeyup). Имя пользователя будет про ряться по мере ввода. Как только пользователь введет уникаль имя, кнопка Далее будет переведена в разрешенное состояние. Вся раз перед выполнением запроса кнопка Далее блокируется, поскол не исключено, что пользователь, продолжая вводить символы, мо" снова сделать введенное имя неуникальным.
Такая проверка правильности содержимого поля ввода должна сочет ся с большой осторожностью, поскольку может сильно увеличить ко. ство запросов. Если сервер не предназначен для интенсивной обрабо запросов, то лучше воздержаться от этого способа.