Обработчик события: как делает jquery?
 

Может кто знает внутренности работы jquery.
Если вешается обработчик события, к примеру click, на все элементы по каком-то условию. То как это реализаует jquery. Вешает обработчик на каждый найденный по условию элемент.
Или вешает глобальный обработчик click, в котором ловит всё и уже потом вызывает нужные обработчики?

Для каждого элемента навешивается обработчик события.

// Bind the global event handler to the element
					if (elem.addEventListener)
						elem.addEventListener(type, handle, false);
					else if (elem.attachEvent)
						elem.attachEvent("on" + type, handle);
				}

Только я не понимаю зачем вам это знать? разница будет лишь в скорости работы помоему..

Именно скорость меня и интересует.
Собираюсь на одной странице сделать Google map и Yandex Map + каталог на jquery.
Поэтому важно делать так, чтобы тормозило меньше.

Ого :) А зачем два мапа?

В google map мой город более детально показан. Но а yandex map - типа "поддержи своего производителя". Так что можно будет выбирать, на какой карте смотреть и при желании смотреть сразу на обоих.

Да и задача интересная - скрестить два api

Любимая привычка программистов сваливать выбор чего-либо на пользователя. Он только путаться от ваших карт будет.

Яндекс, кстати, сегодня выкатил из беты вторую версию карт. Там тоже ваш город плохо показан?

Если сделать всё "по-умному", то пользователь путаться не будет.

Зато сайт не будет зависеть от одного API, что хорошо.
Да и я буду знаком с обоими API, что тоже неплохо.
К тому же можно будет выбирать наиболее актуальную на текущий момент карту.

Для моего города масштаб не изменился.

Ну две карты имхо плохо. Почему не пять? :)

По теме:
Неужели вы смели подумать, что разработчики jQuery не заботятся о производительности?
Это же OpenSource! Кто-то обязательно заметил бы ляпы, и попросил бы их исправить, или включился в комманду и исправил сам.

Как только освою ещё какой-нибудь API, так сразу подключу.

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

Вы реально думаете, что там нет косяков?

Я реально думаю, что если там находятся косяки - их достаточно быстро исправляют.

Утопическое мнение. Те, кто могут заметить ляпы, просто не пользуются jQuery.

я могу заметить ляпы одного из мало-известных php-фреймворков. И я им пользуюсь. Просто беру и коммичу исправление бага.

Есть простенький анализатор серверных логов, простенький , но мне понравился. visitors. Офсайт давно брошен - автор видимо там не появляется. Вся гостевая завалена вопросами о поддержке IE7.
Поняв все вышеупомянутое я залез в код на Си, добавил пару строк и отправил майнтайнеру пакета в debian. Через пару недель пакет с моим патчем и поддержкой IE7 уже лежал в testing репозитории. Я сделал хорошо себе и кому-то еще.

Утопия?
Для этой утопии OpenSource и существует.
И склонен предполагать, что со всеми OpenSource проектами ситуация такая же.

Я обещаю, если замечу "ляп" в jQuery - обязательно отпишу разработчикам, приложив исправляющий патч.

Там несколько версий была проверка typeof o == 'array', это о многом говорит.

Так же о многом говорит то, что сейчас такой проверки нет.
Опечатки бывают у всех.

И вопрос... если вы заметили такой ляп - почему не отписали багрепорт?

Это не опечатка, это глупейшая ошибка.

Как я понимаю, так делается в навешивании через .live().
Event Delegation это называется.

А оно мне зачем? Я не использую jQuery.

Сейчас в jQuery неправильно определяется поддержка прозрачности ($.support.opacity), не такие уж старые версии оперы оказываются в пролете.

Так пишите подробные багрепорты разработчикам.
Неправильно определяется? Знаете как правильно определить? Пишите багрепорт, прикладывайте патч! ( большое спасибо за вклад в развитие)

Я не знаю как сейчас, но правильней было бы поставить перенавешивание обработчиков на все события при событии изменения dom-дерева - думаю так и сделали

Я не согласен, что это правильно.
В-первых, это бы адски тормозило при любом изменении дерева средствами jQuery — алгоритм не тривиальный, обход дерева — ресурсоемкая задача.
Во-вторых, изменения сделанные нативными DOM-методами (или через другие фреймворки) не отслеживались бы (да, я знаю про DOMchanged или как его там, но в IE это не поддерживается).
В-третьих, уже довольно давно существуют техники, которые позволяют осуществить все то же самое быстрее, проще и изящнее.

Возможно вы правы. Я сразу оговорился, что не в курсе... надо будет посмотреть.
Но думаю в случае обрабатывания каждого события и делегация обработчика тоже.... при каждом mousemove ...
В общем надо посмотреть как реализовано для самообразования...

> В-первых, это бы адски тормозило при любом изменении дерева средствами jQuery — алгоритм не тривиальный

Reglib не тормозит. Во всяком случае, на каком-то классе изменений.

ЗЫ не надо спекулировать этими "быстро-медленно", современные компы таковы, что практически все догадки обламываются :)

Артем Шалхаков, не надо спекулировать «современными компами»:) У пользователя может быть не очень новый комп. А приложение может быть довольно ресурсоемким.
Reglib, судя по всему, делает LoadAndTraversal только для невсплывающих событий типа submit'а — там без этого не обойтись, да.

Shasoft,
на баше как раз к вашему случаю цитата

Народ так активно обсуждает тему, как будто только и ждал, пока я тему открою. :)
Я тут почитал, что народ пишет и пришел к выводу, что самое простое, это повесить обработчик на div, внитри которого и будет находится дерево каталога. А в обработчике уже проверять, на чем конкретно нажал пользователь.

Только вот в target/srcElement будет сам этот div, а не элемент дерева. Придется поплясать с бубном, что бы определить, кого там щелкнули.

Или без бубна как то можно?

Кажется, нет, как раз в target/srcElement — элемент, на котором произошло событие. А в this будет div, на который навешен обработчик.
См. http://www.quirksmode.org/dom/w3c_events.html#t04: «The target property refers to the HTML element the event actually took place on, even when the event handler has been registered not on the HTML element but on one of its ancestors»

Ага, туплю помаленьку. Что это со мной. Сам не понимаю.

Но это все равно будет не тот элемент. По крайней мере, если он (нужный элемент) содержит в себе другие элементы. Нужно будет перебирать parentNode-ы и выделять нужные элементы по какому-то признаку. Если дошли до body значит клик вне того, что там кто-то выше задумал сделать.

Опять туплю. Если долго не спать то такое случается. :)

Не без этого, да.

+1
так как непонятно, что это за обработчики и зачем, то ответить что-то сложно. Скорее всего, подойдет уже упомянутая event delegation, тоже довольно просто. А если интересует скорость - сделай несколько вариантов и сравни их производительность, выясни, что тормозит и оптимизируй

ну прикольную дискуссию развели...
Даже интересно попробовать становится, правда чтоб не изобретать коней двухколесных нужно сначала на OpenSource посмотреть, понять что не нравится, потом попробовать по своему и посмтореть - лучше ли получится...

А то что не нужно спекулировать производительносьтю компов - это правда!

да, я не дописал:
"выясни, что тормозит и оптимизируй", если думаешь, что пользователь это оценит (заметит)

Не очень новые? Это минимум одноядерный 1Ghz/256Mb RAM, исключая всякие там неттопы и сотки, но даже и в сотках довольно производительные интерпретаторы, не надо их просто заставлять делать всякую пургу.

О ресурсоемком приложении тоже неясно. Кто-то пишет рейтрейсеры в JS? ^_^

Готовое приложение и профилировщик в студию. У меня самого не очень мощный комп, заодно и проверю. :)

ЗЫ дваждую x-yuri

Математические обсчеты отдыхают по сравнению с DOM-операциями.

Профилировщик вам?:) Напишите:)