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

Daniel Zwolenski zonski at
Thu Dec 8 17:50:16 PST 2011

> Can't I just do:
> PersonView {
>    WritableValue<String> getFirstNameField();
>    WritableValue<String> getLastNameField();
>    WritableValue<Gender> getGenderField();
> }
> I should be able to do this today, and implement it trivially (the
> PersonViewImpl for getFirstNameField() would return
> textField.textProperty(), for example). I don't think it really adds an
> argument for HasValue itself, which still seems to be really only
> beneficial to tools and frameworks (which is still a good thing).

Yea, nice, although WritableValue isn't observable and doesn't support
binding. Also implementing it 'trivially' for a ChoiceBox is not quite true
because of the whole selection model not being writable thing, but this is
back to the ChoiceBox API debate, rather than the HasValue debate.

> 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, 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
 * default means of allowing user input is via a {@link TextField}, a
 * {@link #converterProperty() string converter} property is provided to
 * for developers to specify how to translate a users string into an object
 * 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}.

More information about the openjfx-dev mailing list