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

[Daniel Zwolenski]

Good discussions on this.

I agree with Tom (who agrees with me :) ). Having a 'value' property and a
HasValue interface feels a little more honest to me. Binding to the value
of a choicebox is how I would conceptualise it in my head, whereas binding
to a checkbox might imply that I am binding to all properties of it or
maybe its visual properties. You can see newbies trying to bind to it and
hoping they will get notified when its bounds change, etc.

Also I reckon making it a separate value will make it easier to
implement/extend. If I build a custom date picker, I simply have to expose
my ObjectProperty<Date> as the value property and I'm away, whereas if I
have to extend an AbstractValueControl it gets messy.

With respect to the property for List, Tree and Table (i.e. things that
support multselection), I think we need to support the two basic use cases.
Single selection, I want to use my list much as a I would use a ChoiceBox,
so the value is just the currently selected row. Multi-selection I want to
have an observable list that I can watch and get the selected values from.

To me the most workable solution from the end users perspective is to have
two fields: a HasValue.valueProperty() and a HasValues.values()
ObservableList. It would be nice if there was a cleaner way, but if we go
the ObservableList for the value then we end up with an ObservableProperty
containing an ObservableList which makes the multi-selection painful (I
have to listen to both for changes) and the single selection even more so
(I have to list to both, then map to my single value).

Just my thoughts anyway.



On Wed, Dec 7, 2011 at 11:19 AM, Tom Schindl <tom.schindl at bestsolution.at>wrote:

> 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.
>
> Tom
>
> --
> 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
> http://www.BestSolution.at                      phone    ++43 512 935834
>