Motionbox EventHandler: Event Subscription and Delegation
Ajaxian » Motionbox EventHandler: Event Subscription and Delegation - 持續關注中。簡單的講就是在 document.body observe 所有 bubble 上來的 event.
As you know, the technique of listening to events high in the DOM adds a lot of benefits. The two most notable are:
1. The ability to bind to events before the elements are available in the DOM. This is especially useful for AJAX applications where the DOM is being updated as there is no need to (re)create all your observers. Using this library, the developer doesn't care if an element exists or not, he/she can simply say "any thing with this class works this way" and "anything with this ID does this" All with a simple interface: MBX.EventHandler.subscribe("#myId", "click", myHandlerFunction);
2. Since we handle events outside of the usual manner, custom event handling becomes trivial. The subscription interface is exactly the same, and custom events can be fired easily with: MBX.EventHandler.fireCustom(domElement, "my_custom_event_name");
A Look at Sun.COM's New Event Delegation Library - Gregory Reimer's Weblog
How is this even possible?
Two facts conspire to make this feasible. 1) The <body> (document.body) is available almost immediately. 2) Most events bubble. All you need to do is to stand on document.body, and you're privy to almost every event that occurs on the page, right out of the gate. No need to go seeking out the elements you need, they literally bubble their way to you. All you do is grab the event's target and ask the question, does this element, or one of its ancestors, match 'ul.foo > li > a.bar'? If so, run the associated function, if not, ignore it. This is really just event delegation, and it's nothing new, but we've made little use of it on Sun.COM before now.
Limitations, caveats, dangers
I harbor no illusions this is a perfect solution. There are limitations. Besides the fact that not all events bubble, much of time, behavior depends exclusively on preprocessing, especially if you're doing progressive enhancement. You don't want non-JS users to see useless expand/collapse signs or widgets laying around, so you build the widgets only if scripting is enabled. And the only time to build the widgets is onload. And the only way to build the widgets in the right place is... *sigh* traversal. Some of this can fortunately be avoided by relying as much as possible on CSS and making your widget styles depend on a dynamically-added class name, such as body.jsenabled, so there's some workaround potential at least.
There's also an inherent performance limitation. Sitting in the driver's seat on document.body isn't always a relaxing cruise through the countryside. It can easily turn into rush-hour gridlock, with a flood of events each demanding to be checked. For that reason, I dare not use this technique to handle mousemove events. That would cause a veritable torrent of events. Even mouseover events are iffy. We have the capability and it appears to work reasonably well, but time will tell whether it's really viable. Click events, on the other hand, because of their relative infrequency, are a good candidate. Of course, as we develop this thing further, we'll be looking for ways to mitigate performance risks.
沒有留言:
張貼留言