Forwarded to public-weba...@w3.org On Fri, Apr 24, 2009 at 14:52, Alex Russell <slightly...@google.com> wrote: > On Fri, Apr 24, 2009 at 2:42 PM, Boris Zbarsky <bzbar...@mit.edu> wrote: >> Alex Russell wrote: >>> >>> Something missing from this (and from Erik's original mail) is the >>> ability to enumerate listeners. >> >> This has been brought up before. >> >> 1) There are some serious security concerns here. >> 2) It's not clear what the enumeration should actually return. >> EventListener objects? JS Function objects? Something else? >> Last I checked people couldn't even agree on this (both have >> pros and cons). > > Array of function objects. That would let you do useful things with it > like unshifting onto the front or slicing to remove some set of > listeners. > >> And other than a debugger, I have yet to see a usecase for this. Do you >> have a specific one in mind? >> >>> Even in the XHR case, adding more than one listener is currently a >>> pain. >> >> How so, exactly? > > Aaron's note about addEventListener solves it, but in the common case > where a JS system wants to have multiple callbacks, they either wind > up carrying around their own event listener system (e.g., > dojo.connect()) or a Deferred pattern to wrap functions which only > support direct dispatch from a single call site. > >>> Part of the goal here would be to make event dispatch across >>> lists of listeners as natural in JS as it is in DOM. >> >> The only natural thing in DOM is the event flow from target to root. That >> concept doesn't make much sense in the absence of a linear data structure >> (the list of ancestors, here). > > I think what I'd like to see is a way for this interface to allow > arbitrary JS object to specify what their "ancestor" is. That way > hierarchical JS objects can dispatch "up". > >> Is your real use case just to call a bunch of listeners in a defined order? > > Consider some API that defines an "event": > > thinger = { > happened: function(){ > // processes some state here > } > }; > > Today, JS toolkits provide various ways of listening for something > invoking this. In Dojo, I'd say: > > dojo.connect(thinger, "happened", function(){ ... }); > > Other systems have similar conveniences, but in general they all exist > to keep developers from needing to do: > > (function() { > var old_happened = thinger.happened; > thinger.happened = function() { > // ... > return old_happened.apply(this, arguments); > }; > })(); > > This method of building "callbacks" on existing APIs is not, to use > your word, "sane". > > Regards >
-- erik