Всем привет.

Вообщем порывшись и поразмышляв, так и не нашел ответа.


Вопрос в следующем:
Есть к примеру такой скрипт


Как сделать так, что-бы результат выводился не ВЕСЬ СРАЗУ после того как FOR отработает, а выводился во время работы for, т.е. последовательно?

Т.е. сработала print $i и сразу же появился результат, и пять сработала print $i и опять мы видим результат тут же...



Это сообщение отредактировал(а) bazzjr - 19.11.2009, 08:05

bazzjr, тебе необходимо ориентироваться на AJAX

Немного поподробней можно?

С ajax я на ты, но как применить его?

Если не затруднит приведите пример...

_http://forum.dklab.ru/viewtopic.php?t=34661
_http://forum.dklab.ru/viewtopic.php?p=172547

Зависит от того, для чего это нужно.
Если бы увидеть реальный пример, а не искусственное получение из сферической таблицы мильёна строк, тогда можно было бы ответить более конкретно.

Нужно следующее:

Имеем функцию, в которой происходит считывание данных(блоками) из источника, и некий парсинг этих данных...
Нужно чтобы в определенный момент(например после блока считанных и отпарсированных данных) происходил вывод информации на экран в браузер, после этого продолжилось бы считывание и парсинг данных дальше...

Все это работает на РНР, никаких посторонних скриптов не используется.

По ссылкам выше, посмотрю - спасибо!

Вопрос: Если бы увидеть реальный пример.

Ответ: Имеем функцию, в которой происходит считывание [некоторых] данных(блоками) из [неизвестного] источника, и некий парсинг этих данных...

спасибо.

в данной ситуации так или иначе необходима группа последовательных однотипных ajax-запросов. Первым запросом можно узнать количество записей в выборке. Исходя из полученного клиентом количества, можно в браузере же рассчитать соответствующее необходимое количество запросов для последовательного показа запрашиваемых данных. Т.е. после получения кол-ва записей (например 1000), делаем запрос на выборку с лимитом - 0, 10. Показываем  первые 10, далее 10, 10, затем 20,10 и т.д. до 990,10. Это один вариант.

Второй вариант - первый запрос запускает скрипт для выборки, также для получения общего количества. Далее запущенный скрипт в цикле записывает записи из БД во временные файлы пакетами, скажем, по 10 записей в любом удобном виде (json или xml, или даже csv), именуя файлы соответствующими именами, позволя.щими идентифицировать содержащийся в нем пакет записей. Ну а ajax последовательно делает запросы на эти временные файлы. После запроса на последний файл, посылается ajax-запрос на сервер для удаления этих файлов.

Что-то в этом роде. 

Но на мой взгляд первый вариант более грамотен. Хотя бы потому, что нет риска засорения файловой системы.

Наверняка, если поразмышлять, то в пределах этих примеров можно придумать множество различных вариаций.

ob_flush() ?

хммм... sad8c  возможно ты прав, хотя бы в том, что есть множество вариантов... Дело в ом что такой вид запросов будет не только к базе, но и просто к данным из переменных массива, поэтому второй варик более близок на первый взгляд...

awers мне кжется это не то что нужно, хотя от примера бы не отказался... 

P.S.  я так то думал это не проблема сделать подобное, а оказывается этим мало кто занимался(если вообще занимался)...

bazzjr, Как уже сказали подойдет простой вывод буфера flush();



А разве так трудно зайти на http://php.net и посмотреть там?  http://ru2.php.net/manual/en/function.flush.php там даже примеры есть.





1000 записей вывод по 10 итого нужно сделать 100 запросов.  Очень интересное решение. Второе решение ещё интереснее. Если запустить данный скрипт последовательно, несколько раз или прервать выполнение что произойдет?

Это сообщение отредактировал(а) capitan - 20.11.2009, 02:09

естественно этот пример был абстрактен. но разве для того, чтобы последовательно выводить промежуточные результаты какого-либо ресурсоемкого процесса, не нужно делать запрос на каждый набор строк?



Именно поэтому я и указал на неэтичность данного решения, т.к. оно грозит засорением файловой системы. Но на мой взгляд, возможны задачи, в которых была бы удобной ситуация использования файлов xml/json/csv в качестве буфера, при этом разумеется снабдив систему нехитрым сборщиком мусора. cron, events в помощь. Мало того, абсолютно не составляет никакого труда оградиться и от намеренной перегрузки файловой системы. Все зависит от задачи и логики её реализации. Просто цель всегда должна оправдывать средства)

Нет не нужно. Достаточно просто выводить результат из буфера на экран. А не нагружать систему никому не нужными запросами.