[dojo-contributors] Event handling proposal

Tom Trenka ttrenka at gmail.com
Wed Mar 16 14:01:27 EDT 2011

"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
architectural decision?"

Not having looked at the patch yet, I am going to guess that it's the
result of a ticket I submitted a while ago, where I was having issues
with handlers firing at different rates on different browsers
onscroll.  Same issue exists for things like resize, etc.  Since I put
in that ticket, I've heard (occasionally) from others about how they'd
love a feature like that.

It's one of those things that when it's not there, you try to pull a
workaround but when it is, you wonder how you did without it.

Hope that helps--

On Wed, Mar 16, 2011 at 12:35 PM, Eugene Lazutkin <eugene at lazutkin.com> wrote:
> Hash: SHA1
> Inline.
> 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:
>> http://bugs.dojotoolkit.org/attachment/ticket/12451/events.diff
> 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
> +0.
>> * 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);
> +1
>> * 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
> architectural decision?
>> * 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
> implementation.
>> 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
> capacity.
>> 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.
> Cheers,
> Eugene
>> Thanks,
>> Kris
>> _______________________________________________
>> dojo-contributors mailing list
>> dojo-contributors at mail.dojotoolkit.org
>> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> iEYEARECAAYFAk2A9PUACgkQY214tZwSfCuShwCgjAM1MRhSSq5Wevi+D5xW91fk
> wUkAoKOgssRoSzuFc74uAhCiER740v8Y
> =rJlV
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at mail.dojotoolkit.org
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

More information about the dojo-contributors mailing list