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
