[development] "Subclassing" the standard #autocomplete form

[Steven Wittens]

> An example of the type of widget I'd want would be a "Country  
> Selection"
> widget where what I really want is the two-character country code (US,
> CA, GB, FR, and so on),  but I want the user to think of typing  
> "United
> States",  "Canada", "Great Britain", "France" or so on in order to get
> the popup  to get set on this code.

Why do you need to submit the country code through the form? If the  
autocomplete is smart enough to change "Canada" into ".ca", then the  
code that processes the form can do so too.

Various requests have been made top make the autocomplete 'smarter',  
by letting the displayed value be different from the submitted value.  
Usually, this is an abuse of the autocompleter that would be better  
solved by custom code, and it doesn't degrade without JavaScript at all.

As far as subclassing autocomplete, the menu scout module does  
something like this. But I would only do it if you need significantly  
different behaviour.

Here's how I would do it:
- Make the text field always take a country name. It is the most user- 
friendly input format.
- When the user types something, it does an ajax request to the  
server to look up the country and its code. If it is found, it is  
returned in a list that shows "Country (country code)" e.g. "Belgium  
(be)". Clicking a suggestion will fill in "Belgium", not "be".
- When the user submits the form, the field value (country name) is  
compared to the database and the first match is used.
- If nothing matches, a validation error is thrown. This applies both  
to JS and non-JS, as you can still type in random crap.

For JS users, they get a nice, user-friendly direct autocomplete. Non- 
JS users just have to wait for the whole form to submit instead, but  
still get completion and validation.

To really spice it up, you can use a suffix unit on the autocomplete  
field to display the country's flag, when found.

Steven Wittens