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

[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