autocomplete behaviour

[Wichert Akkerman]

I am struggling a little bit with the intended behaviour of the
autocomplete widget. Currently possible items have a value (which the
plugin calls the 'result' currently) and a label. The label is shown in
the suggestions menu. Once you select an item its value is shown in the
input field. This approach is problematic for systems where you want to
use an internal value such as a database id. Currently in those
situations you will end up with a UI like this:

+----------------------+
Select your city: | Leiden |
| Leiderdorp |
| ... |
+----------------------+

<user selects a city>

+----------------------+
Select your city: | 16 |
+----------------------+

as you can see this is not very user friendly. For these situations you
want to have a value which is returned to the server, a label which is
shown in the input field for a selected item, and optionally a longer
info text which is shown in the suggestions menu. The Selectmenu widget
supports that model, but does not scale well when you have many possible
options.

In my application I always want to return an internal id instead of a
human-readable label to the backend, so the current autocomplete
approach does not work for me. I am considering to refactor it to
support value/label/info data for items. Most likely that will mean that
we need a new hidden input element to store the selected value, and
rename the original input or select element.

Before I embark on that mission I'ld like to hear some feedback from
other. Does thus sound like a sensible approach?

Wichert,

[Scott González]

I agree we need to support that use case as it will be very common. However, I wonder if it could be built as an extension to the autocomplete plugin. The autocomplete currently supports returning as much data as you want for each item, requiring at least a value or label and leaving everything else untouched. This means you can already pass extra data which accommodates the need to pass a value, display label, and a selected label. So, at this point you can pass the value you want to display once selected as the result, the value you want to display in the menu as the label, and the value you want to submit as some third key. Then you can bind to the change event, which will be passed all three values and store the third key (submit value) into a second input element.

Conceptually this seems like it's all possible right now, just not in a clean way by only using options. If that's true, we could figure out the API we would like to use for this model and then build an extension that exposes that API. There are other use cases I would like to see as well that I think would be solved by implementing this generically. One use case would be updating multiple fields or elements when an option is chosen (username + icon, city + state, etc.). Another use case would be running an autocomplete field off of data you don't control via a 3rd party app - the data may not have a label or result key, so you'd need to normalize the data yourself.

--

You received this message because you are subscribed to the Google Groups "jQuery UI Development" group.
To post to this group, send email to jquery...@googlegroups.com.
To unsubscribe from this group, send email to jquery-ui-de...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jquery-ui-dev?hl=en.

[Jörn Zaefferer]

Maybe I'm missing something, but it sounds like all that is already possible. Take a (closer) look at the remote-jsonp visual test: http://jquery-ui.googlecode.com/svn/branches/dev/tests/visual/autocomplete/remote-jsonp.html

A lot of data is coming back from the request. Only the name-field is displayed in the input, while extended data is displayed in the suggestion list. You could put even more data into each row and use that in the change-callback, which currently just outputs the label into a log area. That would be the right place to put an id into a hidden field (or better yet, an index, and map that index back to the id on the serverside).

Considering that everyone has their own way of doing this, its hard to abstract that behaviour into the plugin itself. I've looked at a lot of those in the years maintaining my standalone jQuery autocomplete plugin... not much common ground there.

Jörn