[REVIEW] ComboBox Control

[Richard Bair]

I think this API is good, if there are any concerns that come up we can always adapt it (well, until we ship it anyway :-)).

Richard

On Dec 15, 2011, at 12:55 AM, Jonathan Giles wrote:

> Responses inline....
> 
> -- Jonathan
> 
> 
> On 15/12/2011 6:06 p.m., Daniel Zwolenski wrote:
>> Looks good from the quick look I've had.
>> 
>> A couple of questions (if any of these are in the docco just tell me off):
>> 
>> * Any support for look-ahead-auto-completion? Ie when the user types it filters the list of options and/or selects the best match.
> Not in the 2.1 timeframe, but this is likely for a future release. The big problem is the approach: auto-fill the text field (with the untyped text appearing selected so it can remain editable), show a filtered list, or just jump to the item that matches the most-recent input. All approaches are valid, and different applications will certainly want all three approaches (and others) to work :-)
> 
> Taking this discussion to a (new) Jira issue at some point would be good, just to record things for the future.
> 
>> * What happens if the stringconverter fails? I think you said the selected item goes to null? I assume the text stays the same? Any way for us to detect the failure with a property or some such (what about an 'error' CSS pseudo class as well)?
> The thinking is that when StringConverter is converting a String into an Object using fromString, it sets the ComboBox.value property to whatever is returned from the StringConverter. So, if the StringConverter fails to convert and returns null, the value will become null, and the selection model will indicate that no selection exists. I just wrote some unit tests for this and they fail, but that is my intended approach.
> 
> At present there is no way to detect failure, but this will likely form a part of a future validation API.
> 
>> * maybe a tough one: lazy loaded items to select from. Is this do-able on the proposed API. Hardest bit might be showing a 'loading' indicator in the Popup while the items are being loaded, and possibly not 'committing' an edit of free-type text until the list has been loaded?
> Lazy-loading is supported in the same way as ListView - by providing a custom subclass of ObservableList that can retrieve values on-demand (i.e. when get(i) is called). From my understanding this is being used by developers already and seems to work fine.
> 
> However, with your second point, this is not how the ComboBox works - the user-typed input is not validated against the items list. This means that, even in the case of an on-demand list, there is no need to pull down all values in the ObservableList.
> 
> Of course, if the input will only be allowed if it is an element  of the (on-demand) list, I imagine the developer will need to provide a StringConverter that will implement fromString and only return an Object if the typed string can be found in the on-demand list. If it isn't, it should return null.
> 
>> Oh, wasn't there a proposal for a binding-with-conversion. Just to check that your stringfornatter doesn't overlap with that? Possibly some consistency on that one could be nice if it makes sense.
> Hopefully Michael can chime in on this. I can't imagine any problem, but I'm not involved in the binding APIs.
> 
> -- Jonathan