[dojo-contributors] Event handling proposal

Kris Zyp kzyp at dojotoolkit.org
Wed Mar 16 10:29:02 EDT 2011

On 3/16/2011 1:01 AM, Bill Keese wrote:
> Hi Kris, thanks for working on this.   From your description it sounds
> really great.
> I looked over the patch briefly, although it's a lot of changes so
> it's hard to analyze it thoroughly.     I guess this code isn't quite
> ready to run yet?  fx.html doesn't load for me on either FF or IE9.

I only took it far enough to pass the first half of
dojo/tests/_base/connect unit tests. I'll get the rest straightened out
and do an update later.
> Other comments inline:
>     * 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);
> Looks good, sounds like the so-called ondijitclick could leverage that
> framework.
>     * 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).
> Eugene will probably have more comments about aop.js and listen.js.  
> IIRC he already had a version of the events code that's smaller and
> backwards-compatible, in the dojox.aop area.

I have looked into dojox/lang/oo/aop and dojox/lang/aspect, The aop I
wrote was advised by his work (pun intended), and I am not opposed to
using more of Eugene's code. My intent with aop was to have a more
minimalistic module can simply do before and after advice and also
provide the pause/resume functionality necessary to do add listeners to
simple objects.

>     * 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.
> Didn't quite follow the code in keypress.js, I know for IE you need to
> generate faux keypress events for non-printable characters (otherwise
> you just get a keydown event), but it looks like you are listening for
> keypress events in order to generate keypress events:
> return listen(object, "keypress", function(evt){
> ...
> // simulate a keypress event
> var faux = _synthesizeEvent(evt, {type: 'keypress', faux: true, charCode: c});
I got that one wrong. You're right, it should be listening to keydown.
>     - mouseenter/mouseleave handling - moved to dojo/mouse.js as a custom
>     extension/emulation event.
> About mouse.js, I wanted to test to make sure that your faux-feature
> detection for the mouse-button code is doing the right thing for IE9
> (both standards mode pages and quirks pages), but like I said above,
> can't run the code yet to check.
>     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.
> +1
>     * 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)
> You mean like http://bugs.dojotoolkit.org/ticket/9692 ?
> Are you saying that widgets could emit custom events (ex:
> onWidgetClick)  that bubble up the DOM tree?   Apps could (for
> example) listen for those events on dojo.body()?
I hadn't intended to get that far with it, I was just going to do plain
method calls (and as an base class, it can only be a base class for JS
objects, not DOM objects). The intent was more to align with Node style
EventEmitter. The DOM triggering sounds cool though.
> Pete, you were working on that but got stuck and couldn't finish.  
> What was the issue you had?
>     * list provides separation of events and methods. You can have a "start"
>     method that conditionally triggers a "start" event (mapped to
>     "onstart"), for example.
> Didn't follow this.

Sorry, this was kind of a vague reference to earlier discussions on
separating methods and events.

More specifically, dojo/listen would follow the DOM paradigm of an event
name being prefixed with "on" to get the slot name.
define(["dojo/listen", function(listen){
    var obj = {};
    listen(obj, "foo", function(){ alert("foo event")});
    obj.onfoo(); -> alert "foo event"
    obj.foo = function(){ alert("foo method");};
    obj.foo(); -> alert "foo method"
dojo.connect would still retain it's current behavior of using the same
namespace for method and event.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20110316/fad45718/attachment-0001.htm 

More information about the dojo-contributors mailing list