Устранение общих подвыражений порадовало. Только в сложных программах, наверное, сложно делать подобные оптимизации.
А как обстоят дела по отношению к циклам? Например, будет ли цикл for(i=0; i<2; i++) развёрнут в линейную структуру? При генерации Schematic из VHDL такое точно может происходить
>Я подозреваю, вы куда-то пытались перенести в дереве File Input
Не правильно подозреваете. Возможно, я не корректно высказался. Race condition там происходит из-за рекурсивного вызова обработчика onChange. File input изменился — вызвался onChange. В onChange произошло считывание значение input'a. Ie7 думает, что input опять изменился. Опять вызывает onChange
>Вы хоть в википедии почитайте, что такое race condition…
Угу, и про железнодорожные семафоры там же почитать? Работал, знаю
>Не должны они обрабатываться, Опера все делает правильно.
Вот именно, что не должны. Тем не менее в логе была изменённая строка. А в ней base64 закодирование изображение «Подождите, загрузка»…
>то необходимо размещать его в дереве DOM в отдельной форме
Ага. Этим и занимаюсь позже, динамически таская его по DOM-дереву
>трудно обнаружить ошибки загрузки файла в ифрейм
Это точно. Кроме таймер так ничего и не придумал. Хорошо хоть всё на своём сайте и в запросах не ограничен…
Нет, не пробовал. Тем более у нас стоит лимит на количество изображений (6 штук) + на их размер. Так что реально одновременно будут загружаться не больше 6 изображений
Если фрейм один — то одновременная загрузка не будет работать (по очереди — будет). У нас фрейм вынесен прямо в шаблон с html-кодом загрузчика. Каждому загрузчику свой фрейм
Таймер… Если полоска прогресса не двигается больше определённого времени, то на сервер высылается лог об ошибке, а JS-часть пытается переотправить файл. Физически его будет принимать уже другой сервер
1) JQuery. У нас не используется
2) Готовые модули намного тяжелее тесно интегрировать в свои скрипты. Так же чтобы оптимизировать нагрузку в них надо хорошо разбираться
Абсолютно все исключения, к сожалению, не перехватишь :( Например, если сервер физически вырубили шваброй — то ближайшие пару минут он уже точно ничего не вернет. А JS часть должна уметь обрабатывать и такие проблемы
Ну это же не инструкция или HowTo для начинающих, а вспомогательный материал указывающий, где именно могут быть подводные камни. Я даже не претендую на то, что мои решения были самыми правильными. Однако они работают
Простейший код скрыт за словесными конструкциями. Например:
«нужно обрамить отображаемый frame в невидимый div (display: none)» следует понимать как "<div style="display: none"><frame>...</frame></div>"
А как обстоят дела по отношению к циклам? Например, будет ли цикл for(i=0; i<2; i++) развёрнут в линейную структуру? При генерации Schematic из VHDL такое точно может происходить
Не правильно подозреваете. Возможно, я не корректно высказался. Race condition там происходит из-за рекурсивного вызова обработчика onChange. File input изменился — вызвался onChange. В onChange произошло считывание значение input'a. Ie7 думает, что input опять изменился. Опять вызывает onChange
>Вы хоть в википедии почитайте, что такое race condition…
Угу, и про железнодорожные семафоры там же почитать? Работал, знаю
>Не должны они обрабатываться, Опера все делает правильно.
Вот именно, что не должны. Тем не менее в логе была изменённая строка. А в ней base64 закодирование изображение «Подождите, загрузка»…
>то необходимо размещать его в дереве DOM в отдельной форме
Ага. Этим и занимаюсь позже, динамически таская его по DOM-дереву
>трудно обнаружить ошибки загрузки файла в ифрейм
Это точно. Кроме таймер так ничего и не придумал. Хорошо хоть всё на своём сайте и в запросах не ограничен…
2) Готовые модули намного тяжелее тесно интегрировать в свои скрипты. Так же чтобы оптимизировать нагрузку в них надо хорошо разбираться
Простейший код скрыт за словесными конструкциями. Например:
«нужно обрамить отображаемый frame в невидимый div (display: none)» следует понимать как
"<div style="display: none"><frame>...</frame></div>"