- From: Garrett Smith <dhtmlkitchen@gmail.com>
- Date: Tue, 1 Mar 2011 00:00:27 -0800
- To: Anne van Kesteren <annevk@opera.com>
- Cc: WebApps WG <public-webapps@w3.org>
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