Pull to refresh

Comments 11

прикольно.
Вот только как быть с ситацуией, скажем ползователь иницировал один запрос ПЕРЕДУМАЛ и иницировал другой.
Очевидно что в некотром количестве случаев в зависимости от сервиса удобнее организовывать не очередь а стек.
По принцыпу «последним вызван, первым обработан».
Если не прав поправте.
Но за статью спасибо — лаконично и очень ёмко.
Механизм, при котором один запрос отменяет другой нужно отдельно реализовывать, и вроде стек тут не нужен — если пользователь передумал, то зачем выполнять старый запрос, он просто отменяется.
Можно еще проще (Flapjax):

var ev = blindE(clicksE(button),100); // только те нажатия, которые происходят с интервалом в 100мс
var resp = getWebServiceObjectE(mapE(toreq,ev)); // поток ответов по AJAX

(toreq принимает event, возвращает запрос к серверу)

Теперь resp можно подсоединить куда следует, и все. :-)
«К сожалению, хотя и верно, но срабатывает только в части браузеров, а, например, последний firefox 3.5 просто не выполняет такой запрос.»

А можно пруфлинк? Используем синхронные запросы не один год на всём зоопарке браузеров, и горя не знаем. В FF 3.5 не было замечено никаких проблем (используем для динамической загрузки js, так что невыполнение или асинхронность загрузки заметили бы сразу же).
у меня в Iceweasel(типо тотже ff под linux?) время от времени такой эффект наблюдается.
Дайте ссылку на ваш сайт я гляну его.
> завести массив из объектов XMLHttpRequest, и выполнять каждый запрос к серверу через свой объект. Неоптимально и неудобно.
обоснуй

> открытие полностью всех товаров одним кликом (в этом случае сразу образуется очередь из 20 элементов, которая затем постепенно очищается)
сервер не жалко?
В MooTools есть функция chain, которая позволяеть делать цепочку из функций, следующая начинает выполнятся только тогда, когда выполнится предыдущая. Это, конечно, не будут паралельные запросы, но решает проблему с одновременными запросами (и тем самым, вылетом некоторый запросов). Сам намучился с этим в ExtJS
UFO just landed and posted this here
Если в цепочке запросы просто на получение контента — то при закрытие странички на это пофиг. А вот если на сохранение или удаление данных — то тут конечно придется отказаться от очереди.

Либо сделать как, например, на google docs. Там при закрытие странички, если запросы еще выполняются, появляется confirm-окошко, и требуется подтвердить, что вы хотите закрыть окно браузера. Вариант: сделать такую же штуку, и если пользователь все равно закрыл окно — никто не виноват, что данные не сохранились или действие не сработало.
NikitaG, если хочется именно стек, тогда, я думаю, придется отказаться от выполнения AJAX-запроса прямо из функции, а делать по таймеру. Все приходящие запросы складываем в стек, а какой оказался наверху в момент срабатывания таймера — тот и делаем. Хотя… а если пользователь в этот момент захочет еще один запрос сверху сделать? Тогда опять приоритетность потеряется.

Я сделал именно очередь, потому что так ведет себя посетитель сайта — открывает страницу, прокручивает сверху-вниз и «прокликивает» интересующие книги. Потом прокручивает обратно наверх и смотрит, что наоткрывалось.

sergonavt, вот: http://moiknigi.com/user_books1.php?uid=1030

работоспособность: опера 9.24 — на ура, ff 2.0 — долго думает, но все же открывает, IE6, ff 3.5 — вообще никак. Под safari, говорят, тоже нормально.
мой вариант везде нормально.

tenshi, если завести массив из 20 запросов, а потом все их одновременно стартануть, то тогда как раз да, серверу поплохеет. А так все запросы спокойно стоят в очереди. Один выполнился — за ним следующий, и так далее. Из всех мыслимых вариантов обновления информации этот, на мой взгляд, самый «гуманный» для сервера.
Спасибо.
Мы не используем onreadystatechange с синхронными запросами и, оказывается, не зря :) Просто проверяем .status и затем получаем .responseText — и всё работает.
Sign up to leave a comment.

Articles