[development] better autocompletion?

[Simon Lindsay]

John Handelaar wrote:
> Bèr Kessels wrote:
>> Op dinsdag 18 april 2006 16:33, schreef John Handelaar:
>>> How about amending the autocomplete results to (eg)
>>>
>>>     Title (Author, Date) | nid
>>>
>>> ?
>>
>> AFAIK it was Dries who said 'we should never use nids or other 
>> database specific keys in our frontend'. 
> 
> You misunderstand.  The nid part is the field value
> for autocomplete.

But then you have the nid value there in the form, instead of the text, 
which sounds ok, until you answer a phone call while entering, and 
forget what you were up to, and wonder what 23897 actually stands for again.

What I am/was after was a way to do autocomplete matching and display, 
but store the nid. This would require a hidden field in addition to the 
visible field. The hidden field is set when a match is made/clicked, and 
the visible field shows the "human" representation. On submit, the 
"human" representation is discarded, and the db stores the nid.

In my case it was for stock pricing lookup. I've worked around this 
unsing an autocomplete match that is a built string containing the 
unique stock id (which is ok to show people as they will get to know the 
common ones), as well as the description, separated in a fixed manner I 
can explode() later on.

When the form is submitted, the save function explodes the values, and 
uses them to lookup the actual nid.

The problem is if someone changes the code before saving, or perhaps the 
title of the node before saving, it may no longer match, causing a 
revalidation sequence.

Storing the nid would always be correct, but the javascript autocomplete 
needs to be smarter to be able to do that.

Simon