Элемент, который вы пытались найти, не был в DOM , когда ваш скрипт работал.
Позиция вашего DOM-зависимого скрипта может оказать глубокое влияние на его поведение. Браузеры анализируют HTML-документы сверху донизу. Элементы добавляются в DOM, и сценарии выполняются (как правило), когда они встречаются. Это означает, что порядок имеет значение. Как правило, скрипты не могут найти элементы, которые появляются позже в разметке, потому что эти элементы еще не добавлены в DOM.
Рассмотрим следующую разметку; сценарий # 1 не находит Итак, что вы должны делать? У вас есть несколько вариантов: Переместите свой скрипт дальше по странице, перед закрывающим тегом тела. Организованный таким образом остальная часть документа анализируется до того, как будет выполнен ваш скрипт: Примечание: размещение скриптов внизу как правило, считается лучшей практикой . Отмените свой сценарий до тех пор, пока DOM не будет полностью проанализирован, используя Примечание. Вы можете просто привязать к Делегированные события имеют преимущество в том, что они могут обрабатывать события из элементов-потомков, которые будут добавлены в документ позже. Когда элемент вызывает событие (при условии, что это bubbling g6], и ничто не останавливает его распространение), каждый родитель в родословной этого элемента также получает событие. Это позволяет нам привязать обработчик к существующему элементу и примерным событиям, когда они пузырятся от его потомков ... даже те, которые добавлены после присоединения обработчика. Все, что нам нужно сделать, это проверить событие, чтобы узнать, был ли он поднят нужным элементом и, если да, запустите наш код. jQuery Примечание: Обычно этот шаблон зарезервированы для элементов, которые не существовали во время загрузки или , чтобы избежать прикрепления большого количества обработчиков. Также стоит отметить, что, пока я прикреплял обработчик к Используйте атрибут [ Для справки, вот код из этого внешнего скрипта : Примечание: атрибут
Вариант 1: Переместите свой скрипт
Вариант 2: jQuery's
ready()
ready()
:
DOMContentLoaded
или window.onload
, но у каждого есть свои оговорки. jQuery ready()
предоставляет гибридное решение. Вариант 3: Делегирование событий
on()
выполняет эту логику для нас. Мы просто предоставляем имя события, селектор для желаемого потомка и обработчик событий:
document
(для демонстрационных целей), вы должны выбрать ближайшего надежного предка. Вариант 4: Атрибут
defer
defer
в .
defer
, логический атрибут] установлен для указания на браузера, который должен выполняться после того, как документ был проанализирован.
document.getElementById("test").addEventListener("click", function(e){
console.log("clicked: %o", this);
});
defer
, безусловно, кажется , как волшебная пуля , но важно знать об оговорках ... 1. defer
может использоваться только для внешних скриптов, т. е. для тех, у кого есть атрибут src
. 2. знать о поддержке браузера , то есть: ошибка реализации в IE & lt; 10
Я использую ILMerge почти для всех моих различных приложений. У меня есть интегрированный прямо в процесс сборки конечных версий поэтому, с чем я заканчиваю, один exe на приложение без дополнительного dll's.
Вы не можете ILMerge никакие блоки C++, которые имеют собственный код. Вы также не можете ILMerge никакие блоки, которые содержат XAML для WPF (по крайней мере, я не имел никакого успеха с этим). Это жалуется во времени выполнения, что ресурсы не могут быть расположены.
я действительно писал исполняемый файл обертки для ILMerge, куда я передаю в запуске exe название проекта, я хочу объединиться, и вывод exe имя, и затем это отражает зависимые сборки и называет ILMerge с соответствующими параметрами командной строки. Намного легче теперь, когда я добавляю новые блоки к проекту, я не должен помнить обновлять сценарий сборки.
Мы используем ILMerge на блоках приложений Microsoft - вместо 12 отдельных файлов DLL, у нас есть единственный файл, который мы можем загрузить на наши клиентские области, плюс структура файловой системы намного более опрятно.
После слияния файлов, я должен был отредактировать список проекта Visual Studio, удалить 12 отдельных assmeblies и добавить единственный файл как ссылку, иначе это будет жаловаться, что не могло найти определенный блок. Я не слишком уверен, как это работало бы над развертыванием сообщения, хотя, могло стоить дать ему попытку.
Мы используем ILMerge на довольно многих проектах. Фабрика Web Service Software , например, производит что-то как 8 блоков как ее вывод. Мы объединяем все те DLLs в единственный DLL так, чтобы сервисный хост должен был только сослаться на один DLL.
Это делает жизнь несколько легче, но это не имеет большого значения также.
Мы только что начали использовать ILMerge в наших решениях, которые перераспределяются и используются в наших других проектах и пока неплохо. Все, кажется, работает хорошо. Мы даже запутали упакованный блок непосредственно.
Мы рассматриваем выполнение того же с блоками Библиотеки MS Enterprise.
единственная реальная проблема я вижу с ним, управление версиями отдельных блоков от пакета.
Мы столкнулись с проблемами при объединении библиотек DLL, ресурсы которых находятся в одном пространстве имен. В процессе слияния одно из пространств имен ресурсов было переименовано, и поэтому ресурсы не удалось найти. Может, мы просто что-то делаем не так, но все еще изучаем проблему.
У меня недавно возникла проблема, когда я включил сборку в сборку. У меня были некоторые классы, которые вызывались через отражение в CMS с открытым исходным кодом Umbraco.
Информация для вызова через отражение была взята из таблицы db, которая имела имя сборки и пространство имен реализованного класса и интерфейса. Проблема заключалась в том, что вызов отражения завершался ошибкой при слиянии dll, однако, если dll была отдельной, все работало нормально. Я думаю, проблема может быть похожа на ту, что у longeasy?
Мне кажется, что лучший метод №1 для ILMerge - не использовать ILMerge. Вместо этого используйте SmartAssembly . Одна из причин этого заключается в том, что лучший метод №2 ILMerge - всегда запускать PEVerify после выполнения ILMerge, потому что ILMerge не гарантирует, что он правильно объединит сборки в допустимый исполняемый файл.
Другие недостатки ILMerge:
Другой Стоит обратить внимание на инструменты Mono.Cecil и Mono.Linker [2].
[2]: http: // www.mono-project.com/Linker