[whatwg] Exposing EventTarget to JavaScript

[Erik Arvidsson]

Forwarded to public-webapps at w3.org

On Fri, Apr 24, 2009 at 14:52, Alex Russell <slightlyoff at google.com> wrote:
> 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
>



-- 
erik