[whatwg] Exposing EventTarget to JavaScript

[Giovanni Campagna]

2009/4/24 Alex Russell <slightlyoff at google.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.

DOM = Document Object Model = a set of APIs for representing and
manipulating documents

If you need pure scripting interfaces, you can write your own library,
without reusing EventTarget, that has been used outside its scope with
debatable results. (what does event.stopPropagation() do for
XMLHttpRequest events?)

>>> 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.

Why?
Moreover, is it safe to fully ignore Python or Perl? This is not the
opinion of the SVGWG, in SVGTiny12.
And Java bindings are provided by WebIDL and all DOM specifications.

> 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
>>
>