Недавно взялся разработать новую версию своего парсера лого в сервера SHOUTcast Прасер написан на PHP, при этом активно использует JavaScript (на простом уровне).
Я вообще в JavaScript новичок честно говоря. И меня это непонятное явление тронуло до глубины души, практически шокировав.     

Профессионалы, подскажите в чём прикол) Или в чём моя ошибка, если я туплю  

Чтобы не быть голословным, вот код селектора, написанного на JavaScript (это аналог переключателя страничек в любом поисковике, например в Яндексе, однако аналог скорее всего только лишь по внешнему виду и предназначению, реализовано-то в поисковиках это дело наверняка совсем по-другому    )

PHP-код самого парсера приводить не буду, ибо огромный и сложный. Если потом понадобится, опубликую в отдельном посте. Итак, код нижнего фрейма:



Собственно, дело вот в чём. Во второй версии скрипта при загрузке нового блока PHP-скрипт в верхнем фрейме с помощью JS по событию onload перенаправлял селектор в нижнем фрейме по новому URL, передавая в адресной строке новые параметры, которые использовались селектором для обновления раскладки. Но вот я решил что это не есть хорошо (например, у меня при этом значение поля с именем анализируемого файла очищалось, и почему-то через JS с помощью функции из родительского фрейма не восстанавливалось), и в третьей версии решил сделать механизм, который позволит обновить нужную часть нижнего фрейма без перезагрузки. Для этого я убрал из селектора парсинг URL и вместо этого добавил в функцию вывода раскладки три аргумента.

Сперва я попробовал работать напрямую с document.frm.innerHTML, где frm - имя формы, но, как выяснилось, почему-то данные, добавленные посредством модификации innerHTML из сценария, не читаются, будто их и нет. Поэтому удалить старую раскладку таким способом не получалось. Полностью очистить innerHTML я не мог, потому что там содержался ряд других контролов и надписей. Недолго думая, я нашёл вариант, который уже применял когда-то в другой онлайн-системе с интернет-радио: завести глобальную переменную и хранить в ней исходное состояние innerHTML. Да, наверное это ужасно плохой стиль, но я ничего лучше не придумал. Оно заработало.

Но тут я подумал: а почему мне надо обязательно пихать таблицу с номерами внутрь формы, ведь можно сделать ей отдельный контейнер! И очищать его перед обновлением. Сказано - сделано. Я сделал всё как описано выше, и тут начинается фантастика.

В вышеописанном коде есть оба варианта решения - через глобальную переменную и через отдельный контейнер (второй сейчас закомментирован). Парадокс в том, что второй, более человеческий способ тормозит как не знаю что. Я специально проводил отсчёт времени переключения между страницами данных. В случае помещения трекера в отдельный див, между нажатием на ссылку и осуществлением загрузки верхнего скрипта, который после её завершения вызывал JS функцию селектора, я успевал досчитать до девяти (!). То есть около 9 секунд. В случае же хранения HTML разметки формы в глобальной переменной, при всей нелепости подхода, я едва успевал сосчитать до двух (1,5-2 секунды!)   

Я до сих пор слегка в ауте. PHP-код один и тот же, остальное не менялось, единственное существенное отличие которое я вижу - в первом случае использован метод document.getElementById() (при чём документ мягко говоря не очень большой, пара инпутов, форма, див и обчёлся), во втором же случае происходит обращение упрощённым способом к самой форме: document.frm

Я конечно слышал, что ссылки на формы хранятся браузером как-то особо, для упрощённого вызова. Но getElementById() используется повсюду!.. Ну не верю я чтобы он у всех так тормозил. Он что, ТАК долго обходит дерево?  Какие тогда возможны альтернативы?  

Или я где-то жёстко затупил... Прошу помочь разобраться! 

Это сообщение отредактировал(а) popov654 - 14.8.2011, 08:15

Всё, я уже кажется понял в чём дело. Я ступил)

Похоже, проблема как раз-таки в том, что в случае с отдельным контейнером поле с файлом не очищается. Хоть я и сделал в PHP логику, чтобы при наличии загруженного файла на сервере и установленной куке в клиенте повторной загрузки не происходило, возможно, данные каким-то образом всё же утекают и передаются на сервер снова через форму. То есть такая огромная задержка вызвана тупо повторной загрузкой 5-мегабайтного файла. Но PHP судя по отладочной печати его не сохраняет. Может ли быть так, что данне передаются "вхолостую"? То есть послали, но не приняли?..

И если это так, то вопрос остаётся только один: как с этим бороться? Каждый раз грузить весь огромный лог - Боже упаси, а очищать поле не хочется, т.к. для пользователя это единственный источник информации о том, какой лог он анализирует. Сделать отдельный "дисплей" с именем файла? Увы, у меня места на него нет, да и пустое поле загрузки смотрится не очень красиво...
Можно ли как-то обойти эту проблему через JS? Например, запретить загрузку на сервер части формы?

Можно конечно вообще форму не сабмитить, а только пренаправлять верхний фрейм с PHP-скриптом. Это так, но что делать, если юзер-таки захочет загрузить новый лог?

Надо вообще разделить процесс загрузки файла с логом и процесс переключения страниц. Но как это сделать органично? Тут ведь в чём была прелесть - нажал "Анализ" - и тут же получил результат, так как скрипт в конце стадии подготовки сам устанавливал текущую страницу в ноль и шёл работать дальше. Для пользователя всё было совершенно прозрачно. Кроме того, в ближайшие 10 минут пользователь мог нажать "Анализ" вообще не выбирая файл. Скрипт сам соображал, что файл уже загружен и брал его с сервера. Если сейчас эти процессы разделять - может выйти неудобно с точки зрения юзабилити. Буду думать   

Это сообщение отредактировал(а) popov654 - 14.8.2011, 22:01

Модераторы, переименуйте пожалуйста ветку. Никакого шока тут в сущности нет, обычная глупость