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