[whatwg] Exposing EventTarget to JavaScript

[Alex Russell]

On Fri, Apr 24, 2009 at 2:42 PM, Boris Zbarsky <bzbarsky at 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