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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
