#java #ajax #internet-explorer #tree #wicket
#java #ajax #internet-explorer #дерево #wicket
Вопрос:
У меня проблема с Wicket NestedTree в InternetExplorer 10/11. Когда у меня есть узел, у которого число дочерних элементов — около 5000, то после попытки расширения узла ie зависает, пока я не остановлю выполнение javascript. В firefox, opera, более старой версии ie (7 — 8) все в порядке, загрузка длится всего несколько секунд.
Реализация NestedTree основана на ajax-запросах, и мне интересно, есть ли у более новых версий ie проблемы с ajax-запросами hudge. Проблема не на стороне сервера, потому что запрос выполняется быстро. Когда я попробовал profile IE во встроенном профилировщике, я заметил быстрый рост использования памяти после расширения. Использование увеличилось до 800 МБ, а затем приостановлено. У кого-нибудь была подобная проблема? У кого-нибудь были идеи, что может вызвать проблему?
Ответ №1:
Основная проблема (IIRC) с огромными ajax-i-fied компонентами в Wicket заключается в том, что каждая ссылка / поведение Ajax получает одну строку javascript, которая ее инициализирует. Для небольших чисел это нормально, но если у вас есть страница, состоящая из 1000 AJAX-ссылок, это становится медленным.
Существует обходной путь, который я успешно использую, и он заключается в замене всех AJAX-ссылок на метки setOutputMarkupId(true) и добавлении a OnChildEventBehaviour (см. Мой Код на github) к некоторому родительскому элементу. Затем в этом родительском элементе используйте идентификатор event компонента ‘s, чтобы найти идентификатор в дереве компонентов.
Комментарии:
1. К сожалению, когда я изменил компонент ссылки Ajax на обычную метку, расширение узла длится слишком долго. Во-первых, браузер не приостанавливается полностью, мне не нужно останавливать выполнение Java script, но проблема в том, что это слишком долго. У кого-нибудь есть другая идея? Странно, что проблема выполняется только в IE. Что может вызвать это?
2. Другая причина, по которой это занимает много времени, вероятно, заключается в том, что у вас также много HTML, который необходимо проанализировать… По моему опыту, javascript должен был сделать свое дело. Можете ли вы проверить дерево / источник DOM, чтобы увидеть, действительно ли количество строк javascript значительно уменьшается?
Wicket.Ajax.ajax({"u":"....? Возможно, у вас все еще есть какой-то другой javascript, который занимает много времени.3. Действительно, я заметил, что в ответе html (запрос после расширения узла) у меня много строк с
Wicket.Ajax.ajax({"u":"....4. Тогда к узлам подключено либо больше AjaxLinks, либо AjaxBehaviors. Вы можете копаться в исходном коде дерева и попытаться найти их и заменить их. Это будет неприятная работа.
5. Я попробовал также профилировать в профилировщике IE. Согласно профилировщику, наибольшая продолжительность выполняется во время выполнения функции jquery — обратного вызова. Для запроса, который расширяет узел с 190 дочерними элементами, в ответ у меня есть скрипт, состоящий из 41078 знаков