[REVIEW] ComboBox Control
jonathan.giles at oracle.com
Thu Dec 15 00:55:07 PST 2011
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.
More information about the openjfx-dev