Új hozzászólás Aktív témák

• #3905 martonx veterán CSorBA #3904

  Új Válasz 2014-02-11 16:51:21 #3905

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  martonx

  veterán

  válasz CSorBA #3904 üzenetére

  A dolog egyrészt egyszerű, másrészt nem.
  Van ugyebár a DOM-unk, aminek egy MEGLÉVŐ elemén ha elsül valahol egy esemény, az szépen elkezd fölfelé "bugyogni" a szölő elemein végig.

  Feladat tud lenni, ennek a felfelé bugyogásnak a megszüntetése, mert nem várt mellékhatásokat okozhat. Pl: egy formot ajaxosan akarsz elküldeni. A submit gomb click-jére feliratkozva hiába csinálsz valamit, ha az esemény tovább bugyog, és végül a default böngészős viselkedés fog elsülni rá, azaz elnavigál az oldal a Form url-jére. Ekkor a click elkapásakor egyúttal meg kell szüntetni a tovább bugyogást is.

  A másik típusú gond ott kezdődik, hogy eseményt kötni csak MEGLÉVŐ elemekre lehet, olyanokra nem amiket ajax-al utólag fogsz beszúrni valahova, és az esemény handler létrehozásakor még sehol sincs.

  Ekkor sincs gond, csak éppen más módszerrel kell lekezelni ezeket az eseteket.

  Én kérek elnézést!

• #3908 Sk8erPeter nagyúr CSorBA #3904

  Új Válasz 2014-02-13 01:15:28 #3908

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz CSorBA #3904 üzenetére

  Hi! Az események buborékszerű felszivárgásáról itt írtam, belinkelve egy példát:
  http://prohardver.hu/tema/weblap_keszites/hsz_10515-10516.html
  http://prohardver.hu/tema/weblap_keszites/hsz_10543-10543.html

  Az AJAX-os betöltött elemekre kötött event handlerekre jó példa a jQuery.on(), ahol a "delegated events" rész az érdekes, itt tök jól elmagyarázza a helyzetet (kiemeltem a nagyon fontos részeket):

  "Delegated events have the advantage that they can process events from descendant elements that are added to the document at a later time. By picking an element that is guaranteed to be present at the time the delegated event handler is attached, you can use delegated events to avoid the need to frequently attach and remove event handlers. This element could be the container element of a view in a Model-View-Controller design, for example, or document if the event handler wants to monitor all bubbling events in the document. The document element is available in the head of the document before loading any other HTML, so it is safe to attach events there without waiting for the document to be ready.

  In addition to their ability to handle events on descendant elements not yet created, another advantage of delegated events is their potential for much lower overhead when many elements must be monitored. On a data table with 1,000 rows in its tbody, this example attaches a handler to 1,000 elements:

  $( "#dataTable tbody tr" ).on( "click", function() {
  alert( $( this ).text() );
  });

  A delegated-events approach attaches an event handler to only one element, the tbody, and the event only needs to bubble up one level (from the clicked tr to tbody):

  $( "#dataTable tbody" ).on( "click", "tr", function() {
  alert( $( this ).text() );
  });

  [...]

  Attaching many delegated event handlers near the top of the document tree can degrade performance. Each time the event occurs, jQuery must compare all selectors of all attached events of that type to every element in the path from the event target up to the top of the document. For best performance, attach delegated events at a document location as close as possible to the target elements. Avoid excessive use of document or document.body for delegated events on large documents.

  jQuery can process simple selectors of the form tag#id.class very quickly when they are used to filter delegated events. So, "#myForm", "a.external", and "button" are all fast selectors. Delegated events that use more complex selectors, particularly hierarchical ones, can be several times slower--although they are still fast enough for most applications. Hierarchical selectors can often be avoided simply by attaching the handler to a more appropriate point in the document. For example, instead of $( "body" ).on( "click", "#commentForm .addNew", addComment ) use $( "#commentForm" ).on( "click", ".addNew", addComment )."

  Itt tehát a példában az eseménykezelőt a tbody-ra kötötte, ahelyett, hogy az összes tr-re tette volna ugyanezt, így az eseménynek csak pontosan egy szintet kell buborékszerűen felúsznia, a klikkelt tr elemből a tbody felé.

  Ide felraktam egy egyszerű példát:
  http://jsfiddle.net/Sk8erPeter/Tpc3k/
  itt például gombokat adok hozzá egy container elemhez. Az első példában csak az első gomb "reagál" (dob alert() ablakot), mert konkrétan a kód lefutásának pillanatában jelenlévő button elemre kötöttem az event handlert; a második esetben viszont amikor hozzáadok újabb gombokat, azok is dobnak alert()-ablakokat, hiszen ott azt határoztam meg, hogy a szülőelemre legyen kötve az event handler (egyébként itt a lényeg a hierarchia, nem az, hogy közvetlen szülőeleme legyen!), és megadtam egy selectort is (ami a "button"), hogy a leszármazott elemek közül ezekre szűrjön az eseménykezelés során, ezek triggereljék a click eseményt.
  Lásd a doksiban a leírást a selectorra:
  selector
  Type: String
  A selector string to filter the descendants of the selected elements that trigger the event. If the selector is null or omitted, the event is always triggered when it reaches the selected element.

  Tehát a különbség:
  első:
  $container1.find('button').on('click', function (event) { ... } );
  második:
  $container2.on('click', 'button', function (event) { ... } );

  Remélem, nagyjából érthető, ha valami nem tiszta, mert bonyolultan írtam, kérdezz nyugodtan

  Sk8erPeter

Új hozzászólás Aktív témák