[dojo-contributors] Event handling proposal

Kris Zyp kzyp at dojotoolkit.org
Tue Mar 15 17:29:38 EDT 2011


Looking at how to add has() branching for dojo/_base/event.js and
considering other improvements that I have wanted to see in our event
handling, I put together a rework of the event system I wanted to
propose to you. This is based on work from Bryan, ideas from Eugene,
current discussions on dojo.touch, has, and more. This diff is here:

http://bugs.dojotoolkit.org/attachment/ticket/12451/events.diff

It is not quite complete, but most of functionality is
in there. This is intended to be fully backwards compatible. Here are
the main improvements/ideas:

* Uses has() branching
* Function event types, allowing you to create new custom/extension
events (like dojo/touch.press) in a safe extensible way. Special
handling of certain key events (keypress, onmouseleave, and onmousenter)
are implemented using extension events. For example:
dojo.connect(node, dojo.touch.press, listener);
* Introduce a new lightweight dojo/listen module/function that can be
used sans the large blocks of corrective code for keypress,
onmouseleave, and onmousenter emulation (particular useful to avoid for
mobile apps).
* Modularization - Trying to improve the modularity of our event handling:
There is several distinct pieces of functionality in dojo/_base/event.js
that is broken out:
- keypress handling - this is moved out to dojo/_base/keypress.js as a
custom extension/emulation event.
- mouseenter/mouseleave handling - moved to dojo/mouse.js as a custom
extension/emulation event.
- aop - Used for listening to regular object's methods, can be used on
its own, but leveraged by listen module (dojo/aop)
- listen - The main listening component, this does not do include
special code for specific events, but it does include the IE event
normalization code.
- connect - Back-compatible delegation to the other modules, if you look
in connect.js you will see how it does the magical mapping of named
events to these custom events
Note that some of these ideas for aop/listening have been suggesting for
2.0. However, this patch adds this functionality without breaking
compatibility, so it seems like it might be viable in 1.x.
* NodeList.prototype.on() maps to listen() function -
dojo.query(".class").on("some-event", callback);
* Return value from connect() and listen()/on() is an object with three
methods:  cancel(), pause(), and resume()
dojo.disconnect(handle) still works, but can do handle.cancel() instead
(as well as pause and resume)
* dojo/listen provides an Evented base class that can be extended for
event emitting objects, providing on() and emit() methods (could be used
by a future widget class hierarchy)
* list provides separation of events and methods. You can have a "start"
method that conditionally triggers a "start" event (mapped to
"onstart"), for example.

Not done (didn't want to go too far without feedback):
* Pub/sub (easy to finish)
* Only a little bit tested
* Memory leak handling for IE (if we want it)

Other ideas:
* Maybe rather than dojo/listen we do dojo/when, and then when() is kind
of uber-function for asynchronicity, handling both event registration
and promises?

Anyway, it is somewhat substantial rework, so curious what you think. Is
this worth considering?

Thanks,
Kris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20110315/0078b18c/attachment.htm 


More information about the dojo-contributors mailing list