Controls with Values [was Possible additions to JavaFX to facilitate forms and validations]

[Jonathan Giles]

>> There is another problem though, with a ChoiceBox the "value" is supposed
>> to be limited strictly to those items contained in the selection list. It
>> isn't a ComboBox -- there is no possibility to add custom items. Yet when
>> you add a "value" property to ChoiceBox, as the ChoiceBox author, you have
>> to accept that sometimes people will set something that isn't in the list.
>> SO basically to make ChoiceBox usable with binding, we have to give up the
>> invariant that the selected item is always one of the items in the list.
>> Unavoidable it seems.
>>
> I think the same argument on the value not being in the list applies to
> selectionModel.select(T), so whatever rules are being used there should
> carry over.
>
> Looks like Jonathan has already put something in place for the ComboBox
> free-type text issue. He's got a 'StringConverter' in there that maps the
> entered text to a 'value' (and there's a valueProperty already there for
> us). I haven't quite worked out what happens if the text doesn't map to a
> value but I'm guessing a null value in this case.
>
>   *<p>Because a ComboBox can be {@link #editableProperty() editable}, and
> the
>   * default means of allowing user input is via a {@link TextField}, a
>   * {@link #converterProperty() string converter} property is provided to
> allow
>   * for developers to specify how to translate a users string into an object
> of
>   * type T, such that the {@link #valueProperty() value} property may
> contain it.
>   * By default the converter simply returns the String input as the user
> typed it,
>   * which therefore assumes that the type of the editable ComboBox is
> String. If
>   * a different type is specified and the ComboBox is to be editable, it is
>   * necessary to specify a custom {@link StringConverter}.

In general I'm staying out of this rabbit hole, but I thought I'd reply 
here seeing as I was explicitly dragged into the discussion :-)

So, for starters, ComboBox is preview API - it may change drastically 
once people start providing API feedback (yeah, Rich, I'm looking at you 
:-). Moving past that, the value property in ComboBox represents the 
current value of the ComboBox (I'm sure my English teacher would frown 
on me using the term in the definition, but alas, I digress). To 
clarify, the current value is either the last selected item from the 
items list, or the last input text typed by the user (in the case of an 
editable ComboBox) - whatever happened most recently.

What this means is that the StringConverter can take a user-typed 
String, attempt to convert it to T, and then set it in the value 
property - without the T object actually being a part of the items list. 
The value, if it does not exist in the items list, is NOT added to the 
items list - I leave that as a challenge for the end-developer. However, 
this can be trivially done if that is the UX expectation: simply add a 
listener to the valueProperty, and updating the items list when it 
changes (and if the item is not already in the list).

Conversely, the StringConverter is also used in the opposite direction 
to convert a selected item of type T into a String, such that it may be 
edited by the user in the ComboBox TextField. Upon the user pressing 
enter, this String is converted back to type T, and set in the value 
property. Again, this does not result in the items list being updated.

Hope that clarifies things with respect to the ComboBox. For what it is 
worth, if you have specific feedback on ComboBox API, let's please move 
it to a separate thread - it's not my intention to deep-dive any further 
on ComboBox and hijack this thread.

-- Jonathan