W3C home > Mailing lists > Public > whatwg@whatwg.org > April 2009

[whatwg] Exposing EventTarget to JavaScript

From: Alex Russell <slightlyoff@google.com>
Date: Fri, 24 Apr 2009 10:33:30 -0700
Message-ID: <6fc58d0d0904241033r1015cf08kf985935625e34132@mail.gmail.com>
On Fri, Apr 24, 2009 at 10:30 AM, Giovanni Campagna
<scampa.giovanni at gmail.com> wrote:
> 2009/4/24 Erik Arvidsson <erik.arvidsson at gmail.com>:
>> Almost all JavaScript libraries and web apps of moderate size end up
>> reimplementing events for their UI toolkits or for messaging between
>> different parts of their application. To help out with this scenario
>> it would be good if an implementation of the EventTarget interface
>> could be exposed to JavaScript. This would mean that JavaScript can
>> instantiate and extend event targets and dispatch events to these
>> objects would work just like it does for DOM elements today.
>>
>> For example:
>>
>> var et = new EventTarget;
>> ...
>> et.addEventListener('foo', fun, false);
>> ...
>> et.dispatchEvent(eventObject);
>>
>> would call the handler fun.
>>
>> The example above actually works today if you replace "new
>> EventTarget" with "document.createElement('div')".
>
> This should not work. This is because the DOM event system (used for
> elements) is different from the scripting event system (used for
> windows, xmlhttprequest, workers, etc.). The former requires a
> document through which the event flows (capture - target - bubble
> phases). No document => no event.

This is a bug, not a design constraint.

JavaScript should be extended to support event dispatch (as Erik
outlines) and it should be done in such a way as to cast the DOM event
system as an implementation of that dispatch mechanism. Suggesting
that JS and DOM shouldn't be more tightly integrated because they
havent' been more tightly integrated in the past isn't a legit
argument.

>> The next and more important step is to allow a JavaScript "class" to
>> extend an EventTarget. For example:
>>
>> function MyClass() {
>> ?EventTarget.call(this);
>> ?...
>> }
>> MyClass.prototype = new EventTarget; // *[1]
>>
>> Then addEventListener and dispatchEvent should work as expected on
>> MyClass objects.
>
> This is a matter of host language, not of DOM. In Java, you just do
> public class MyClass implements EventTarget {
> }
>
> and the same in ES6 (ES-Harmony)

It's safe to fully ignore Java.

Regards

>> One more thing needs to be mentioned and that is how event propagation
>> should work in scenario. If the object has a "parentNode" property
>> then the event dispatching mechanism will do the right thing.
>>
>> var o1 = new MyClass;
>> var o2 = new MyClass;
>> o1.parentNode = o2;
>> o2.addEvengListener('foo', fun, true); // capture
>> o1.dispatchEvent(e);
>>
>> In this case fun will be called because the event propagated up to o2.
>>
>> There is one more thing that needs to be done to make this work
>> without a hitch and that is to allow "new Event('foo')" to work.
>> Without that we would still have to do "var $tmp =
>> document.createEvent('Event'); $tmp.initEvent('foo')" which of course
>> is very verbose and requires a document.
>>
>> I see this as a small step to make JS and DOM work better together and
>> I hope that "this is the beginning of a beautiful friendship".
>
> Why do you need an EventTarget?
> In most cases you can emulate the same behavior with a Javascript
> library, without more work on the UA.
>
>> *[1] This can be optimized using js tricks in ES3 and using
>> Object.create in ES5 so that no EventTarget needs to be instantiated.
>>
>> --
>> erik
>>
>
> Giovanni
>
Received on Friday, 24 April 2009 10:33:30 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:11 UTC