Выборка данных с предсказанием - это шаблон проектирования, пр дусматривающий получение данных от сервера. У этой медали ест и другая сторона - передача данных на сервер. Мы стремимся изб жать полных обновлений страницы, поэтому логичен вопрос: когда oi правлять на сервер данные пользователя? При традиционной реалия ции сайтов и веб-приложений каждый щелчок мышью приводит к и редаче запроса на сервер, чтобы сервер всегда знал, что в нестояща момент делает клиент. В случае применения технологии Ajax польа ватель может взаимодействовать с сайтом или приложением без а правки излишних запросов, генерируемых по каждому щелчку.
Одно из решений может состоять в том, чтобы отправлять данные сер¬веру всякий раз, когда пользователь выполняет какое-либо действие,-аналогично тому, как это делают традиционные веб-приложения. На¬пример, символ, введенный пользователем, немедленно отправляется серверу. С каждым новым символом процесс передачи повторяется. С этим подходом связана одна неприятность: дело в том, что он в состо¬янии очень быстро породить массу запросов, что может затормозить ра¬боту не только сервера, но и пользовательского интерфейса, т. к. на обработку и передачу каждого запроса затрачивается какое-то время. Шаблон проектирования с регулируемой передачей данных позволяет обойти это препятствие.
Суть шаблона с регулируемой передачей данных заключается в том, что в процессе работы приложение размещает в некотором буфере дан¬ные, подлежащие передаче серверу, и затем отправляет эти данные в определенные моменты времени. Почтеннейшее веб-приложение Go¬ogle Suggest делает это просто блестяще. Оно не отправляет запрос по¬сле ввода каждого символа, а ждет, пока не истечет некоторый интер¬вал времени, после чего отправляет серверу весь текст, находящийся в этот момент в поле ввода. Задержка между вводом последнего симво¬ла и фактической передачей на сервер подобрана так тонко, что она практически не заметна. Регулируемая передача данных в какой-то степени способствует увеличению скорости работы Google Suggest.
Процесс регулирования начинается либо тогда, когда веб-приложение загружается первый раз, либо по определенному действию пользовате¬ля. Затем на стороне клиента вызывается функция, начинающая бу¬феризацию данных. Время от времени она проверяет активность поль¬зователя (чтобы не мешать его действиям). Если пользователь акти¬вен, функция продолжает накапливать данные. Как только он приос¬танавливается, т. е. не выполняет никаких действий, надо решать, следует ли посылать уже накопленные данные. Критерии при этом мо¬гут быть самые разные: можно отправлять данные по мере их накопле¬ния до некоторой определенной величины или всякий раз, когда поль¬зователь приостанавливает работу. Обычно после передачи данных на сервер веб-приложение продолжает сбор информации до тех пор, пока либо не будет получен ответ сервера, либо пользователь не выполнит действие, которое прервет накопление данных. Блок-схема алгорит¬ма, описывающего этот процесс, показана на рис. 3.2.
Шаблон проектирования с регулируемой передачей данных нельзя приме¬нять для отправки данных, имеющих критически важное значение. Если информация должна быть доставлена серверу в течение жестко ограни¬ченного интервала времени, то лучше рассмотреть вариант на основе традиционной модели, чтобы обеспечить своевременную доставку ин¬формации.