How to Create an Ajax Autocomplete Text Field: Part 11 [con't]
Keeping the List Open on Page Load
Once you've conducted a search, clicked on a list item, or simply gone to another URL, and returned to the AutocompleteCSS.jsp page, you're likely to observe one of two behaviors: Either the search string will still be in the autoComplete text field and the list will have vanished, or the list will remain open and the text field will have lost its contents. Since neither of these behaviors are desirable, let's see if we can't keep both the text field and list in the same state as we left them.
To bring back the list, add the following line to perform the search using the autoComplete text field value. The if statement tests for any non-blank value:
The AUTOCOMPLETE Parameter Bug
The second issue was a lot harder to track down because it wasn't the default browser behavior. An exhaustive search revealed that the AUTOCOMPLETE attribute was the culprit. Although most browsers do recognize it, there's no standardized compliance for it. Firefox, for example, will only recognize it at the form level, while Internet Explorer supports it at the element level. You would expect that browsers who don't recognize the AUTOCOMPLETE attribute would simply ignore it, but it caused my Firefox version 2 to forget the text field's contents between page loads.
AUTOCOMPLETE attribute has got to go. Remove the AUTOCOMPLETE attribute from the complete-field input element in the Autocomplete.jsp page as follows:
Many developers have tried to devise a way to circumvent JSP validator errors caused by the AUTOCOMPLETE attribute. One such solution is to move the functionality from the Web page to JavaScript:
Is it a good idea? One contributor saw the flaw in the logic of this solution and posted it on a Web development blog: "The thing is you're actually just using a JavaScript function to hide the fact that you're using an unrecognized attribute. It's a 'fake' validation because you're using the DOM to add the attribute by stealth in a way the validator doesn't understand. You don't really gain anything, but you make the presence of the attribute dependent on JavaScript being enabled and are replacing one small attribute with a dozen lines of script."
Another impediment to a scripting solution is the lack of a JavaScript "autocomplete" property, which negates the possibility of testing for browser support. Hence, the following line of code fails to work as one would expect:
My advice is to use the attribute at the form level. If you really need it for individual elements, you'd have to set it using JavaScript, making sure that you're dealing with Internet Explorer. We only have one input field, so we'll just add the AUTOCOMPLETE attribute to the <form> tag in the AutocompleteControl.jsp page:
Here's a zip archive containing the two files that we modified today.
That's a wrap on our Autocomplete Control. I hope you learned a lot from this series. At the very least, I think that it demonstrated how Web development is about getting a lot of different technologies, tools and languages to work together to solve a problem. It's important to not get fixated on the same approach for every problem and to keep your ear to the ground for new developments. Perhaps you'll be inspired to contribute to those developments. That's what open source is all about!
References
- Introduction to Java event listeners
- DOM events
- More on DOM Events!
- Canceling events
- Turning off autocompletion in Mozilla-style browsers
Original: August 14, 2008
Digg This
Add to del.icio.us
Find a programming school near you