How to Create an Ajax Autocomplete Text Field: Part 11 | WebReference

How to Create an Ajax Autocomplete Text Field: Part 11

By Rob Gravelle


[next]

Digg This Add to del.icio.us

Creating an Autocomplete Text Field Using the Eclipse Web Tools Platform

Capturing Control Key Events

It's been a voyage of discovery and learning, but our series on the Ajax Autocomplete Control is drawing to a close. Along the way, we learned about the Eclipse IDE, the Eclipse Web Project, JSP pages, how to add a Tomcat server to the IDE, JavaScript, Ajax, JSON and CSS. This week we wrap up the series by adding code to process ENTER and TAB keystrokes, as well as keeping the list open when returning from another page.

As alluded to last time, the ENTER and TAB keys must be handled differently than the other ones. We can't use the keyup event to capture the TAB key because it doesn't fire it. Instead, we'll use the keypress event. Replace any existing code for the keyup event and add the handler for the keypress event in the init() function:

The addEventHandler() Function

The old way to add an event handler to an element was to assign it directly to its event property, using the following syntax:

An obvious drawback to this approach should be apparent. What happens to preexisting handlers? You guessed it. They would be overwritten. As you can well imagine, managing multiple handlers for the same event would be a nightmare. Fortunately, JavaScript has followed in the footsteps of the Java programming language and adopted the Event Listener Model. Instead of assigning a function to the event property, we add it as a listener. As discussed in the last article, there are two major browser implementations of event propagation models: the DOM one, and Microsoft's. To add a listener in Internet Explorer, we would call the attachEvent() function, passing in the event name, preceded by the "on" prefix (i.e.: onclick, onkeyup). DOM compliant browsers use addEventListener(). The addEventListener() function accepts a third parameter to set the bubbling phase at which to execute your handler. Here's an explanation of the DOM bubbling model, taken from my URPMs - Ajax Edition article:

"The World Wide Web Consortium had their hands full when deciding on an event model because the two main standards were diametrically opposed, with Netscape using something called the capturing model, and Internet Explorer endorsing bubbling. Basically, the two camps emerged as a result of answering the questing of what should happen if an element within another element both have handlers for the same event: Should the parent (outer) element fire first, or should the child (inner element)? Netscape concluded that the parent should fire first. That's Event Capturing. Internet Explorer took the opposite stance and decided that the child should be the one to fire first! That's event bubbling. The W3C took the middle road in creating their own W3C Event Model whereby the event is first captured until it reaches the innermost element and then bubbles up again. This allows the developer to select either style of event firing by supplying the addEventListener() function with a Boolean argument. I used "constants" to show that true means capture and false means bubble. In practice, unless you have a specific reason to use capturing, stick with bubbling, as I did here."

In addition to letting you register multiple listeners on the same event, the new DOM Event Model expands its applicability to any DOM Node which supports the listener interface.

The addEventHandler( Node node, String eventName, Function eventHandler) delegate function calls the appropriate method. Rather than use antiquated browser sniffing techniques, it tests for the method on the DOM node:

The TAB Key

The code for the TAB and ENTER keys will reside in a function called handleEnterAndTabKeys(Event e). Here's the basic code for that function with the TAB key handler included:

This handler is similar to the one for the ESCAPE key, which we coded last time. The only difference is we don't suppress the TAB key's default behavior; the result being that it will still move the focus to either the next or previous element on the page, depending on whether or not the SHIFT key was also pressed at the time.


[next]