[dojo-contributors] Event handling proposal

Rahul Akolkar rahul.akolkar at gmail.com
Tue Mar 15 20:05:02 EDT 2011


2011/3/15 Kris Zyp <kzyp at dojotoolkit.org>:
> 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
>
<snip/>

Having taken but a cursory glance at the patch above, I like most of
the sentiments expressed in it (and listed below).

-Rahul


> 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
>


More information about the dojo-contributors mailing list