[dojo-contributors] Event handling proposal
eugene at lazutkin.com
Wed Mar 16 13:35:53 EDT 2011
-----BEGIN PGP SIGNED MESSAGE-----
On 03/15/2011 04:29 PM, Kris Zyp wrote:
> 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:
It doesn't work for me --- shows blank. I'll retrieve it and go over
locally, when I have time.
> 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);
Sounds interesting. It would be nice to see 2-3 real world examples of
that. If it works properly, it could be a fantastic way to define
app-specific and/or generic/synthetic events.
> * 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).
+1. I am all for separating functionality unnecessary in 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
I am all for modularization, as long as the end product works properly.
> 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)
Is cancel() the same as destroy()? Judging by context it is.
BTW, working on the form manager I implemented pause() and resume()
functionality for value-changing events, but globally (manager-wise)
rather than locally (per event connection) --- I couldn't find a good
use case for the latter. Could you share use cases to do that
> * 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)
Again, it sounds good, but the real proof is in its API and implementation.
> * list provides separation of events and methods. You can have a "start"
> method that conditionally triggers a "start" event (mapped to
> "onstart"), for example.
I started to do something like that in Pulsar and on a surface it looks
like a good idea. Again, the devil is in details, in this case in the
> 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)
All this stuff is conceptually simple, so don't worry about it for now.
Just get all conceptual details right --- if we have concepts in place,
we can always tune its implementation to our liking.
> 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?
Again, it was one of points in Pulsar. Right now events (not DOM events,
but abstract language-level events) share the implementation with
promises, yet the API is not compatible. It would be nice to unify them
on some logical level (as opposite to some mechanistic level). I am
really curious about that part and will be happy to help there in any
> Anyway, it is somewhat substantial rework, so curious what you think. Is
> this worth considering?
I think it is definitely worth exploring. And I hope other developers
will join the discussion.
One more thing I wanted to see (and it was mentioned by Bill in his
response) --- ability to create synthetic and/or "natural" browser
events, bubbling such events up DOM hierarchy, and all related things.
Right now we do not provide such functionality directly, yet users ask
about that periodically. It probably should be a separate module outside
of the Base, yet solving the whole thing in complex with others listed
above will bring us so sorely needed consistency.
> dojo-contributors mailing list
> dojo-contributors at mail.dojotoolkit.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
More information about the dojo-contributors