- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Fri, 24 Apr 2009 21:32:45 -0400
Alex Russell wrote:
>> 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.
What about event listeners that are not backed by a JS function? Say
actual objects in JS with a handleEvent function, or listeners
implemented in other languages?
>> 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.
It's still not clear to me what that has to do with the questions I asked...
>> 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".
OK. That makes some sense, assuming that the common case is that there
is in fact at most one "ancestor". I don't have any data on whether
this is the common case; is it?
>> Is your real use case just to call a bunch of listeners in a defined order?
...
> 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);
That still doesn't answer my question. You need such chaining in the
DOM, say, if you use the on* properties. But if you addEventListener,
you can have multiple listeners for a given event. The only caveat is
that dispatch order is undefined. So again, is the goal to have
multiple listeners per event, or to be able to enforce a specific
ordering on them? If the latter, would simply requiring dispatch in
addition order (which is, after all exactly what your example above
does) be sufficient?
> This method of building "callbacks" on existing APIs is not, to use
> your word, "sane".
Oh, absolutely agreed.
-Boris
Received on Friday, 24 April 2009 18:32:45 UTC