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
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 aBoolean
argument. I used "constants" to show thattrue
means capture andfalse
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.