[whatwg] Exposing EventTarget to JavaScript

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

Received on Friday, 24 April 2009 14:54:45 UTC