Procedura dla elementów wczytanych dynamicznie

1

Witam.

Mam następujący problem. Dynamicznie za pomocą AJAX wczytuje kod gdzie między innymi mam:

<span name="dodaj12" id="'.$row->tekst.'" value="'.$oryg.'" class="button">Dodaj</span>

A jQuery wygląda tak:

 $(document).ready(function() {  
	$('span[name="dodaj12"]').click(function(){
         alert('lol');
        });
});

Jak mam dodać akcje do tego buttona skoro jest on wczytywany dynamicznie i jQuery go nie widzi?

1

Dwa różne rozwiązania:
A) Przypisz procedurę obsługi zdarzenia dopiero gdy przyjdzie odpowiedź ajaxowa, a nie przy $(document).ready.
B) Dodaj procedurę obsługi zdarzenia za pomocą funkcji jQuery live(). Poszukaj jej opisu w dokumentacji (http://api.jquery.com ).

1
bswierczynski napisał(a)

B) Dodaj procedurę obsługi zdarzenia za pomocą funkcji jQuery live(). Poszukaj jej opisu w dokumentacji (http://api.jquery.com ).
NIE używaj .live() tylko .delegate(). live zostało z powodów kompatybilności wstecznej, to jak używanie ereg zamiast preg w php ;-)

0

@Marooned:
Piszą gdzieś o tym w dokumentacji jQuery? Osobiście może nawet preferuję delegate() (chociaż nawet o nim nie pomyślałem pisząc posta -- zresztą jej zrozumienie jest ciut bardziej skomplikowane) i używałem delegacji zanim jeszcze wsadzili ją do jQuery. Ale live() i delegate() nie robią dokładnie tego samego. Nie widziałem, żeby gdzieś na stronie jQuery pisali, że live() jest be. Na stronie live() nie ma nawet wzmianki o delegate() (np. żeby tego używać), funkcja nie jest też zdeprecjonowana. Czyżby twórcy jQuery mówili coś o tym poza dokumentacją? Jeśli tak, to mogliby zamieścić w niej odpowiednią wzmiankę.

Tymczasem ereg w PHP to wcielenie zła, licha i jakiego czorta. Funkcja jest od dawna zdeprecjonowana, a jej dokumentacja odsyła do preg_match i stwierdza, żeby zamiast eregów używać funkcji PCRE. Więc zdaje się, że to jednak trochę inny kaliber...

0

live() dokłada się do document i bazuje na "bąblowaniu" eventów w górę po czym sprawdza czy element związany z działaniem jest pasujący.
delegate() dokłada się bezpośrednio do rodzica więc jest efektywniejsze.

nawet o tym wspomniałem swego czasu

Dodatkowo jeśli na jakimś elemencie między naszym a document jest podpięte inny event tego samego rodzaju i zatrzymamy propagację, to live przestaje działać bo event nie dotrze do document. Przy skomplikowanych stronach ciężko to namierzyć i robi się problem dlaczego prosty kod nie działa.

1

@Marooned:
Wiem jak działają live() i delegate(). Pytałem, czy jakieś źródła faktycznie tak mocno używały użycie live() bo zaciekawiło mnie to gdy porównałeś tę funkcję do (rzeczywiście fatalnego) ereg z PHP.

Tak w ogóle to w pewnych przypadkach korzystniejsze wydajnościowo może być użycie opcji A). Konkretnie: gdy zdarzenia na stronie zachodzą często, ale treść jest resetowana rzadko. Wtedy korzystniej jest odpalać silnik selektorów (=skanować DOM) podczas podpinania zdarzeń po aktualizacji treści, a nie po każdorazowym zajściu danego zdarzenia. Zależy to jednak od paru czynników. Podpięcie zbyt wielu zdarzeń do zbyt wielu elementów poprzez zwykłe wywołania bind() może zmulić przeglądarkę. Z drugiej strony, używanie delegate() lub live() przy zdarzeniach typu mousemove też może mulić.

A czy live() ma nad delegate() jakąś przewagę? Chyba nie, może jedynie łatwość nauki (bo przy delegate() wypada już kumać bąbelkowanie zdarzeń; live() to lepiej ukrywa i udaje, że wszystko dzieje się magicznie). delegate() ma natomiast plus wydajnościowy, o którym wspomniałeś i na pewno warto go używać.

1 użytkowników online, w tym zalogowanych: 0, gości: 1