Sorry about the delay in responding - your message got buried in my email...
For value/id issue, I passed another parameter indicating the name of the hidden form element to store the ID in. (I think I called this parameter "valueElement".) The plugin would then create this hidden element and insert it into the DOM after the target autocomplete textbox. If a hidden name value wasn't specified, then the hidden element wasn't created. In this way the developer still had control over the name of the elements that were getting passed to the server. The server side processing is beyond the scope of the autocomplete, so I chose to leave it that way... :) That's how I solved the issue for my own custom autocomplete plugin (which I'm abandoning in favor of the "common" solution, and less maintenance work on my behalf..). That's not to say it is the "right" solution in all cases. I think you have more insight into the autocomplete needs than I do at this time. I'm tempted to just add this functionality to your code and submit it back to you. But your coding style is a fair bit different (deeper level) than my own, and I'm afraid I'd spend too much time learning the details, or messing up something for your code. Your approach seems reasonable, though it seems like more effort than needed. I would assume that the developer using such a plugin would be aware of what element names they are using or want. Adding this ID feature to an existing page would seem to be a revision of the page requirements (in my eyes), so the developer could/should be open to adding another value to pass to the server. Hope that helps. But the rate you do things, you have probably already done this.. :) Thanks again for all your efforts. Shawn Jörn Zaefferer wrote: > > Hi Shawn, > > your feedback is welcome, and you make some good obversavations. > > The least I can say is: I'm working on it. Actually I've implemented a > scrolling result list (both mouse and keyboard navigatable) today and > tuned some other stuff (making it thickbox compatible). > > For a (too) long time I hesitated to promote my "solution" too much, to > avoid lurking people into using a buggy and incomplete solution. Maybe > that decision was wrong. But now I'm very near to be able to release 1.0 > finally. Once that is done, I'll try to promote it, be it on the plugin > page(s), be it on various other resources (say, ajaxian). When starting > work on the autocomplete I talked with Dylan about it, and at least he > has no problem to take his solution down. I'll try contact other > authors, too. > > About the value-id issue: I want to tackle that, too. So far the plan is > to provide an option "replace" or "select" (not sure about the name > yet). Its just a boolean flag. Once set to "true", it'll hide the input > you apply the autocomplete to, create a new one (using the original name > and append some suffix like "_autocomplete"), apply the same classes > etc. and setup handlers to automatically write the select ID into the > hidden field. So while it emulate a select 100% on the clientside, there > won't be any difference for the serverside: The user selects some text, > but submits a value. > > Let me know what you think about these aspects. Even feedback on names > and suffixes is helpful :-) > > Regards > Jörn
