Re: Better event listeners‏

Hi Anne,

Thanks for bringing the case of event registration, this has been a pain in 
DOM/JavaScript for some time already and it's quite clear we can do better 
in this area.

However, I've a few issues with your latest proposal:

    - how do you register more than one handlers for an event?
    - how do you unregister an handler with this proposal?
    - how do you specify properties for your handlers (like shouldCapture)?
and
    - isn't creating an object bag a too high cost for an event 
registration?
    - how do you deal with private names and inherited properties?

What about resurrecting .{} instead?

    element.on.{
        click.{
            remove(oldCallback1)
            add(newCallback1)
        }
        resize.add(newCallback2)
    }

Even if .{} isn't resurrected, I think an 'on' proxy still leaves you with a 
fairly good syntax:

    element.on.DOMContentLoaded.remove(...).add(...).add(...);

If we define "element.on" as a proxy, we can event make it support unknown 
event names by returning an "event handler object" for the event whose name 
as been specified as property name.

That would leave us with two new WebIDL interfaces, and an updated one:

    interface EventTarget {
        readonly EventRegistrationHub on;
    }

    interface EventRegistrationHub {
        readonly EventTarget target;
        /* proxy, returns an event handler for unknown properties whose 
target is 'target' and whose 'name' is the required property name */
    }

    interface EventHandler {
        readonly DOMString name; // the name of the event
        readonly EventTarget target; // the target of the event
        add(callback, options...) // ...
        remove(callback...) // ...
    }

Another benefit is that you could pass an event to a function (now, you have 
to pass the target and the name, and use 
target.addEventListener/removeEventListenee(name, ...)).

Another benefit could be that now you can check for the existence of an 
event by doing if("EventName" in target.on), if we configure the proxy 
correctly (ie return true only if the event is builtin). New events always 
come with an uppercase first-letter name so that we can be sure there will 
be no conflict with future Object.prototype.* builtin properties (if there's 
not one already with the current names, which I believe is not the case).

Last but not least, you can get intellisense (autocompletion) once you typed 
"element.on." in any sufficiently good IDE/dev tool.

Best regards,
François




-----Message d'origine----- 
From: Anne van Kesteren
Sent: Monday, January 07, 2013 2:25 PM
To: es-discuss
Subject: Object iteration order

In "DOM-land" we're designing new APIs that take objects as arguments.
Unless objects meet the criteria in
https://mail.mozilla.org/pipermail/es-discuss/2010-December/012469.html
invocation of the API method might result in implementation-specific
behavior. See also
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20158

Given the convenience of being able to do something like

  element.on({click: callback1, resize: callback2})

we're probably going to run with it, but I thought I'd give a heads
up. Maybe someone here has a better idea or maybe iteration order will
finally be settled on? :-)


-- 
http://annevankesteren.nl/
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Received on Monday, 7 January 2013 16:42:49 UTC