JavaScript Event Proxy

Transferred from: http://www.cnblogs.com/silence516/archive/2009/09/03/delegateEvent.html

If you want to add a bit of JavaScript interactivity to your Web page, you may have heard of JavaScript's event delegation, and think it's one of those puzzling design patterns that enthusiast-level JavaScript programmers will care about. In fact, implementing event proxies is a breeze if you already know how to add JavaScript event handlers (handler).

JavaScript events are the foundation of the interactivity of all Web pages (I mean real interactivity, not just those CSS drop-down menus). In traditional event handling, you add or remove event handlers as needed for each element. However, event handlers can lead to memory leaks or performance degradation-the more you use it, the greater the risk. The JavaScript event Proxy is a simple technique by which you can add event handlers to a parent element, thus avoiding the addition of event handlers to multiple child elements.

How does it work?

The event agent uses two features that are often ignored in the Javasciprt event: event bubbling and the target element. When an event on an element is triggered, such as a mouse click on a button, the same event will be triggered in all ancestor elements of that element. This process is known as event bubbling, which bubbles to the top of the DOM tree from the beginning of the original element. The target element of any event is the first element, in our example, the button, and it appears as an attribute in our element object. Using the event proxy, we can add an event handler to an element, wait for an event to bubble up from its child elements, and know which element the event is starting from.

What good is this for me?

Imagine now we have a 10-column, 100-row HTML table that you want to do when the user clicks on a cell in the table. For example, I once had to make each cell in the table editable when clicked. Adding an event handler to these 1000 cells creates a big performance problem and can lead to memory leaks and even browser crashes. Instead, using the event proxy, you just need to add an event handler to the table element, which can intercept the click event and determine which cell is clicked.

What does it say in code?

The code is simple, and all we have to worry about is how to detect the target element. Let's say we have a TABLE element, the ID is "report", and we add an event handler for this table to call the Editcell function. The Editcell function needs to determine the target element of the event passed to the table. It is possible to use this function in some of the functions we are writing, so let's put it in a separate function called Geteventtarget:

function Geteventtarget (e) {
E = e | | window.event;
return E.target | | E.srcelement;
}

E This variable represents an event object, we only need to write a little cross-browser code to return the target element, in IE, the target element is placed in the Srcelemnt attribute, and in other browsers is the target property.

The next step is the Editcell function, which is called to the Geteventtarget function. Once we get the target element, the rest is to see if it is the element we need.

function Editcell (e)

{
var target = Geteventtarget (e);
if (target.tagName.toLowerCase () = = ' TD ')

{
Do SOMETHING with the CELL
}
}

In the Editcell function, we determine whether it is a table cell by examining the label name of the target element. This check may be a bit simplistic, if it is another element in the target element cell? We need to make a little bit of changes to the code so that it can find the parent TD element. What if there are some cells that don't need to be edited? In this case we can add a specified style name to those cells that cannot be edited, and then check to see if it does not contain the style name before turning the cell into an editable state. Choices are always diverse, and you just need to find the one that's right for your application.

What are the advantages and disadvantages?

The benefits of JavaScript event proxies include:

There are fewer event handlers that need to be created and reside in memory. This is an important point, so that we improve performance and reduce the risk of crashes.
There is no need to rebind the event handler after the DOM update. If your page is dynamically generated, for example through Ajax, you no longer need to add or remove event handlers when the element is loaded or unloaded.
The potential problems may not be obvious, but once you notice them, you can easily avoid them:

Your event management code has the risk of becoming a performance bottleneck, so try to make it short and concise.

Not all events can bubble. Blur, focus, load, and unload cannot bubble like any other event. In fact blur and focus can be obtained using event capture rather than event bubbling (in browsers other than IE).
There are some things to be aware of when managing mouse events. If your code handles MouseMove events, you risk a performance bottleneck because the MouseMove event triggers very often. Mouseout, however, becomes difficult to manage with event proxies because of its bizarre behavior.

Summarize:
There have been some examples of event proxies using mainstream class libraries, such as jquery, prototype, and Yahoo! Ui. You can also find examples that don't use any kind of library, such as this one on usable type blog. Once needed, the event broker will be a handy tool in your toolbox, and it's easy to implement.

JavaScript Event Proxy