preferred way of handling events
in [JavaScript]
|
From: Ry Nohryb on 13 Aug 2010 04:53 On Aug 12, 3:04 am, RobG <rg...(a)iinet.net.au> wrote: > On Aug 11, 5:21 pm, Gerard Ketuma <gket...(a)gmail.com> wrote: > > > So i have studied the DOM level 2 event handlers and have written some > > nifty functions to take care of the browser incompatibilities with > > this model. However, I feel like working with the traditional way of > > handling events, where we assign functions to the event handler > > property, is way easier and makes my code easy to follow. I know there > > are all these benefits to using level 2 event handlers, like making > > the code modular, making it easier for two or more people to handle > > the same event. My question is, which of these models do you > > frequently use? and why? > > There is no one way, it depends on the job. > > Assigning a function reference to an "on" event property is fine where > an element only has one listener for that event (which is most of the > time). Where an element may have more than one listener for the same > event, then other schemes are required. What I hate most about addEventListener is that you need to save a reference to the handler f() if you ever want to remove it afterwards. OTOH, on_xxx properties (DOM0 style) can be setup easily so as to trigger more than a single handler. -- Jorge.
From: williamc on 13 Aug 2010 17:48 On 8/13/2010 4:53 AM, Ry Nohryb wrote: > What I hate most about addEventListener is that you need to save a > reference to the handler f() if you ever want to remove it afterwards. > OTOH, on_xxx properties (DOM0 style) can be setup easily so as to > trigger more than a single handler. > -- > Jorge. Jorge, could you elaborate on the "setup easily so as to trigger more than a single handler?". window.onload = function() { var myDiv = document.getElementById("test"); myDiv.onclick = function() { alert('foo'); } var oldFn = myDiv.onclick; myDiv.onclick = function() { oldFn(); alert('bar'); } var oldFn2 = myDiv.onclick; myDiv.onclick = function() { oldFn2(); alert('bletch'); } var oldFn3 = myDiv.onclick; myDiv.onclick = function() { oldFn3(); alert('blort'); } } ....chains together handlers but requires a new reference for each new handler. That doesn't seem any better than saving a ref for each function added via addEventListener/attachEvent except that you don't have to remove them one by one. So I'm guessing there's a better way to do it. Didn't discover it on a web search, though... -- -williamc
From: Ry Nohryb on 13 Aug 2010 19:30 On Aug 13, 11:48 pm, williamc <te...(a)williamc.com> wrote: > On 8/13/2010 4:53 AM, Ry Nohryb wrote: > > > What I hate most about addEventListener is that you need to save a > > reference to the handler f() if you ever want to remove it afterwards. > > OTOH, on_xxx properties (DOM0 style) can be setup easily so as to > > trigger more than a single handler. > > Jorge, could you elaborate on the "setup easily so as to trigger more > than a single handler?". It's not that I have done it ever, I just meant that -I think- it should be quite easy to do... :-) > window.onload = function() { > > var myDiv = document.getElementById("test"); > > myDiv.onclick = function() { > alert('foo'); > } > > var oldFn = myDiv.onclick; > myDiv.onclick = function() { > oldFn(); > alert('bar'); > } > > var oldFn2 = myDiv.onclick; > myDiv.onclick = function() { > oldFn2(); > alert('bletch'); > } > > var oldFn3 = myDiv.onclick; > myDiv.onclick = function() { > oldFn3(); > alert('blort'); > } > > } > > ...chains together handlers but requires a new reference for > each new handler. Another attempt at it, (not very tested) could be: function addHandler (elmnt, onWhat, newHndlr) { var prevHndlr= elmnt[onWhat]; elmnt[onWhat]= (typeof prevHndlr === "function") ? function (event) { newHndlr.call(elmnt, event); prevHndlr.call(elmnt, event); } : newHndlr; } addHandler(window, "onclick", function(e){alert([this,e])}); addHandler(window, "onclick", function(){alert("The next alert should show the 'this' and the event object")}); > That doesn't seem any better than saving a ref for > each function added via addEventListener/attachEvent except that you > don't have to remove them one by one. Yes, well, in order to remove it, when there's more than a handler attached, one can't avoid the need to identify it, and for that one needs to have saved a reference. But when there was only 1 I find it much more convenient the DOM0 style of nulling the on_xxx property. > So I'm guessing there's a better > way to do it. Didn't discover it on a web search, though... To do what exactly ? To manage more than a handler per event per element ? In all truth, I very very rarely attach more than a single handler. -- Jorge.
From: Thomas 'PointedEars' Lahn on 13 Aug 2010 20:58
RobG wrote: > On Aug 11, 5:21 pm, Gerard Ketuma <gket...(a)gmail.com> wrote: >> So i have studied the DOM level 2 event handlers and have written some >> nifty functions to take care of the browser incompatibilities with >> this model. However, I feel like working with the traditional way of >> handling events, where we assign functions to the event handler >> property, is way easier and makes my code easy to follow. I know there >> are all these benefits to using level 2 event handlers, like making >> the code modular, making it easier for two or more people to handle >> the same event. My question is, which of these models do you >> frequently use? and why? > > There is no one way, it depends on the job. Full ACK. Gerard: We have been over this ad nauseam. Please take heed of <http://jibbering.com/faq/#posting>. > Assigning a function reference to an "on" event property is fine where > an element only has one listener for that event (which is most of the > time). Where an element may have more than one listener for the same > event, then other schemes are required. No, multiple event listeners for the same event and object can be accomplished using proprietary event-handler properties ("'on' event properties") as well, using a user-defined event registry (method; like jsx.dom.addEventListener()). In fact, that is the only way to guarantee in the MSHTML DOM that those event listeners are executed in-order; EventTarget::addEventListener() (which guarantees calls in order of listener registration) is not implemented there, and attachEvent() disregards registration order (not to mention its `this' problem). PointedEars -- realism: HTML 4.01 Strict evangelism: XHTML 1.0 Strict madness: XHTML 1.1 as application/xhtml+xml -- Bjoern Hoehrmann |