This is a JQuery plugin for an editable combobox, built according to JQuery UI 1.5 conventions. There are a couple existing combobox plugins, but they either weren't true comboboxes (dropdown only) or they would fail if you tried typing something non-ASCII into the text field. This uses a different approach: the text field is real, but the drop-down is faked as a collection of spans.
$(selector).combobox() may be called on elements of any type. If the element is a <select> tag, the combobox will attempt to populate itself from the options of the select. Otherwise, the options arguments must have a 'data' field that contains a list of options. By default, those options are displayed verbatim in the drop-down list; you can customize this by providing a function for the listHTML option.
The selected element is completely replaced by a text field, drop-down list, and image to display the drop-down list. The name, class, and id attributes are copied over from the original element to the new input field, and after the call, the JQuery collection will point to the new input field(s). Calling combobox('destroy') will restore the original element.
The drop-down list is keyboard sensitive with the following keybindings:
Additionally, options are auto-selected by typing within the input box.
All event handlers take 2 arguments: the original browser event, and an object with the following fields:
The event handlers are also available as custom JQuery events, following JQuery UI conventions (i.e. select = 'comboboxselect', key = 'comboboxkey', etc.)
Download (tarball) | Download (single file) | API Docs | GitHub Project Page | Online Demo
Haven't tested this, but try $('#selector').combobox('setData', 'data', new_option_list). In general, the setData method on JQuery UI widgets lets you dynamically change options after the widget has been constructed. But it has to be specifically supported by the plugin (there's code in the combobox to do it, but it hasn't been well-exercised).
If it doesn't work, it's a bug. Let me know about it and I'll get around to fixing it sometime.
I've updated the demo page with an example of how to do this.
There's also you'll a bugfix you'll need to get the getData call to work. It's up on both the website (1.0.5) and GitHub.
The first example on the demos page, "Simple combobox from array", has an example of using listHTML. Just have it pick up the text from a JavaScript hash instead of computing it from the index.
Yes, that's intentional. The values in the data array control what will be placed in the input field. The result of the listHTML controls how these are displayed in the menu.
If you want to translate the displayed value into some other value for the server, just write an onSubmit handler that processes the value before submitting to the server. Or put in server-side code to translate the values. That's outside the scope of this plugin.
To rephrase my earlier, waffly, question ;)
How do I display the option text not the value?
Sorry, to clarify, it displays this 'value' to the user when the option is selected (rather than showing the option).
The dropdown looks ok otherwise ...
Why not get rid of the values and just have the option texts? If you need a different value for the database, either put some postprocessing in the server-side code or write an onSubmit handler that checks the value of the form.
The plugin is setup so that the option text controls the menu display and the option value controls the textbox. This is the only way it can work: the combobox is actually a text input, and the value of a text input is submitted verbatim with a form. If the combobox widget itself were to intercept the displayed value before it goes to the server, it would need to know the structure of the form surrounding it, which is basically an encapsulation nightmare.
Jonathan, thanks for the help.
The system I use is localised. So the value is standard and the option text is translated depending on the users language settings.
I can understand why it's the only way combobox would work and post server processing would work in this case.
It's a shame though, as it would be great if it could behave just like the html select it's replacing.
You mean have an input type=hidden, and then update that with the new value whenever there's a change in the text field or a value is selected? Any change needs to take into account that values can both be selected or typed in manually into the field, and that typed values don't necessarily have to be on the list.
Anyway, I see two problems with that:
(Continued in second comment...damn Django Threadedcomments has a length limit.)
You mean dynamically changing the options based on some external event? Yeah; ComboBox responds to the same setData protocol that the other JQuery UI Widgets do. Either call setData('data', newOptions) on the combobox widget itself (which is not the same as the DOM element; you use $('#id').data('combobox') to retrieve it) or trigger the "setData.combobox" event on the JQuery element.
In order to get the events to work properly in jQuery 1.3.1 and above, I had to modify the function called "fireEvent" in the comboxbox.js script (on or around line 317) to the following:
},
making this modification might likely break some other functionality in this plugin but it did the job for me.
Don't worry about it...came through fine in the e-mail.
Thanks for the patch! I'll see about incorporating it when I get a chance.