[REVIEW] ComboBox Control

[Jonathan Giles]

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