[development] "Subclassing" the standard #autocomplete form widget

[Rob Thorne]

The country example was only an example, since it's easy to explain. My 
actual use cases are much larger:

    * Looking up a contact from a voter list... you want the user to
      type from the name, but get back a voter/contact id string or number.
    * Type the name of a political district (say, a Canadian
      parliamentary riding), but get back its ID number.

In these cases, I'd probably have alternate UIs to work with 
non-JavaScript aware clients (say, a search page), since the AJAX and 
non-AJAX versions of the UI would need to be pretty different.

Rob

Gabor Hojtsy wrote:
> On Wed, 17 Jan 2007, Rob Thorne wrote:
>> I really don't need to change behavior very much; I just need to send 
>> back an array of array(key, value), where the standard widget sends 
>> back an array of string values. But pretty much everything else that 
>> Unconed's code does exactly what I want, and while I can copy if if 
>> that's easiest, I don't want or need to change what he did.
>
> How would your widget degrade if there is no JavaScript enabled? It 
> would still need to look up the code for the country name on the 
> server side anyway (or would require the user to provide the country 
> code if that is in a form item). Either way, the Drupal default 
> approach puts less strain on the server, while supporting a discrete 
> JavaScript approach as far as I see.
>
> Gabor