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

Tom Schindl tom.schindl at
Tue Dec 6 16:19:36 PST 2011

Am 07.12.11 00:58, schrieb Richard Bair:
>> I don't think the proposals for Controls to "be" properties will necessarily preclude any of that, but would it be more natural for Controls to talk to a property that is owned by the application?  In other words, TextFoo is a Control that takes a Text property, it is not itself a text property.  And when you do data binding, you would be binding the raw properties that the application manages, not the Control nodes.  And when you have multiple views on the same data open then you don't have to have a cloud of self-important nodes that all believe they own the data that needs to be coordinated so they all make sure they own the same version of the data as each other...
> Well, this is what happens now. So for example, I have a Person object which has a "name" StringProperty. And the TextField has a "text" StringProperty. So I can do:
> textField.textProperty().bindBidirectional(person.nameProperty());
> Really what is being proposed is to just shorten this, such that TextField would also have the notion of a "value" that it was displaying, and you could bind this value, such as:
> textField.bindBidirectional(person.nameProperty())
> The actual data value is still in the "Person" model object, and the TextField is just displaying the result. The only difference is that basically we've taken one property from the TextField and promoted it to represent the "value" of that Control. In another example, I have a List of Person objects as the data model for my ListView. Instead of:
> listView.itemsProperty().bind(controller.peopleListProperty())
> I can just do:
> listView.bind(controller.peopleListProperty())
> I don't think it actually changes the relationship between the data model and the view. In Martin Fowler's terminology, the "record state" (in the database) is the one true record, and then on the client you have "session state" which is whatever view of the record state existed at the time you did your database query, and the "view state" is just a copy of the session state such as it was at the time you last sync'd it. With binding, we keep the "view state" and "session state" fairly well sync'd -- but as far as the app is concerned, the session state is authoritative and the view state is just a copy of the state (usually converted to a String) for the purpose of display or text entry.
> Cheers
> Richard

On List/Table/Tree the value you want to bind is not predefined:
a) items (=content)
b) selection, including multi-selection

I'm not sure makeing the binding directly on the Control is a good idea
because you start to clutter the interface of the control with methods.

I think the important thing Daniel was proposing that Controls have a
way to provide a property with the same name pointing to the "domain
value property" so that there's no difference between e.g. binding the
value of a Text, Checkbox, ... so in fact "valueProperty" is simply a
synonym for Text#textProperty and so all toolings understand this
property by default (including FXML) and don't need to make an extra case.

So I'm with the proposal from Daniel to introduce an interface control
subclasses can implement optionally (it might not make sense to all of
them) and e.g. things like ToggleGroup could implement it as well which
is not a subclass of Control.


B e s t S o l u t i o n . a t                        EDV Systemhaus GmbH
tom schindl                 geschäftsführer/CEO
eduard-bodem-gasse 5-7/1   A-6020 innsbruck     fax      ++43 512 935833                      phone    ++43 512 935834

More information about the openjfx-dev mailing list