Re: [DOMCore] fire and dispatch

On 2/28/11, Anne van Kesteren <annevk@opera.com> wrote:
> On Fri, 25 Feb 2011 18:47:54 +0100, Garrett Smith <dhtmlkitchen@gmail.com>
> wrote:
>> Your example is simple. But some common cases of synth events are
>> complicated. UI Events aren't so bad but MouseEvents and especially
>> TouchEvents are a lot of work to synthesize.
>>
>> Most cases for synth events are for testing -- feature test or unit test.
>>
>> EventTarget.fireEvent(type[, options]);
>
> So how is this simpler? Maybe you could illustrate by example instead?
>
>
It is simpler than the W3C existing model because it doesn't require
any memorization. This is because each property of `options` is
optional. The entire `options` object is optional. If options is not
an object, then a default options object is created internally.

Some examples where that approach is used are in YUI, which they use
for "YUI Test". Another is in TestRunner (I made). Both of these are
unit testing frameworks that can be used to test javascript code
running in a web browser.

YUI is pretty easy to find. The interface of what I made is quite
similar. The idea is that instead of the heavywork of
createEvent("MouseEvent") and then initMouseEvent with 16 args, you
can just:

Mouse.click(document.body, {clientX : 10});
https://github.com/GarrettS/ape-javascript-library/blob/master/src/eventsynth/Mouse.js

No long parameter lists to memorize. And it is extensible in that
future versionso of mouse events can have more options which can be
easily featre tested.

Compare that to:
var mouseEvent = doc.createEvent("MouseEvent");
mouseEvent.initMouseEvent("click", true, true,
                        doc.defaultView, 1, 0, 0,
                        10, 0, false, false,
                        false, false, 1,
                        null);
document.body.dispatchEvent(mouseEvent);

For me, the first one is memorable but the second way (the standard
way) requires me to memorize too much and is easy to make a mistake
with order of arguments.

The adapter also does some workarounds for browser bugs and for IE's
different model. But regardless, even without the differing model, or
bug workarounds, the default API is unnecessarily complicated. At
least for web scripting. For java, too, I suppose.

Nothing ingenious on my part. Makes perfect sense, really.
-- 
Garrett

Received on Tuesday, 1 March 2011 08:00:59 UTC