[development] "Subclassing" the standard #autocomplete form
steven at acko.net
Fri Jan 19 23:37:32 UTC 2007
> An example of the type of widget I'd want would be a "Country
> 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
> 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
As far as subclassing autocomplete, the menu scout module does
something like this. But I would only do it if you need significantly
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.
More information about the development