Live Events, new in jQuery 1.3, give us another tool when dealing with the SP user interface.

Clicking, moving the mouse, and pressing keys all trigger events in the web browser. In JavaScript, we try to capture these events, using event listeners that trigger interactions to control the user experience. In my previous examples, like loadTip-AOP and Preview Pane, I used event helpers to bind listeners to individual DOM elements:

$("a[href*='DispForm.aspx']").mouseenter(function(event){console.log(event);});

Try this: Put jQuery on your page. Run the code above in your Firebug console then move your mouse over a linked Item. On the left side, click the new event object. What type of information does an event hold?

When we use this technique, ExpGroupRenderData, our old nemesis, forces us to bind new events to the new DOM elements (hopefully without binding additional events to existing ones). I used two different ways to trigger this “rebinding” process: rewrite ExpGroupRenderData to include the binding function and AOP to create a sort of callback function.

How Live Events Are Better

As the number of elements on the page increases, the performance of this technique degrades. Event delegation, using live events, attaches the listener to a “container” element so the rebinding process is no longer needed. Additionally, since only the containers need listeners, the initial binding process performs better.

Trade-offs

As of this writing, jQuery 1.3 does not support live events for blur, focus, mouseenter, mouseleave, change, and submit. With a traditional .bind() approach, we can easily manage our 1:1 ratio of listeners to DOM elements. Using event delegation, we must take special care to avoid firing multiple, unwanted events.

Click “Read more…” if you want to see the hands-on experiment.

Hands on

Working with Live Events forces us to work from “most specific” to “most general” with our selectors. For example, open a page with more than one web part pointing to list Items (Tasks, Calendar, etc.). Place jQuery on the page (either a CEWP or the jQueryify bookmarklet) and run the following code in the Firebug console:

$("a[href*='DispForm.aspx']").mouseenter(function(event){
	console.log("1:"+event.target);
});
$("div#WebPartWPQ1 a[href*='DispForm.aspx']").mouseenter(function(event){
	console.log("2:"+event.target);
});

When you mouse over your links you will see either one or two console messages (depending on whether or not the target was inside web part 1). Let’s suppose, you only want one of these to fire. Refresh the page, add the .stopImmediatePropagation() method to our event and try again.

[/sourcecode]
$("a[href*='DispForm.aspx']").mouseenter(function(event){
	console.log("1:"+event.target);
	event.stopImmediatePropagation();
});
$("div#WebPartWPQ1 a[href*='DispForm.aspx']").mouseenter(function(event){
	console.log("2:"+event.target);
});
[sourcecode lang="xml"]

What happened? Well, we’re only seeing one console message but we never see the second function fire, even for links in web part 1. Because our selectors overlap, to achieve the desired results, we have to reverse the order so the browser processes our most specific selector first and stops propagation (the effect of bubbling the event up through the DOM).

[/sourcecode]
$("div#WebPartWPQ1 a[href*='DispForm.aspx']").mouseenter(function(event){
	console.log("2:"+event.target);
	event.stopImmediatePropagation();
});
$("a[href*='DispForm.aspx']").mouseenter(function(event){
	console.log("1:"+event.target);
});
[sourcecode lang="xml"]

Now we get message 2 for our web part 1 links and message 1 for all others.

Conclusion

Live events represent a great option for managing new UI interactions in SharePoint, especially when working with a changing DOM. However, the trade-offs require us to plan and test more to understand where our selectors overlap.

Paul Grenier