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

[Richard Bair]

Hi Dan,

>> The argument in #2 I think is not very strong because HasValue isn't
>> required to fix this. That is, we can add a "value" property to ChoiceBox
>> without having a HasValue interface, so it doesn't address the question
>> "why is HasValue important?".
>> 
> 
> True. The only thing that is arguably 'more intuitive' is the ChoiceBox,
> where the concept of a 'value' is added. This could definitely be done by
> looking at the ChoiceBox/ComboBox in isolation.
> 
> So generally, yes, the proposal of a generic HasValue thing is of most
> benefit to framework development that wants to access fields in a generic
> way.
> 
> There is a style of MVP design pattern however where this generic HasValue
> would be of benefit to the developer. I could create an interface for my
> view like so:
> 
> PersonView
> {
>    HasValue<String> getFirstNameField();
>    HasValue<String> getLastNameField();
>    HasValue<Gender> getGenderField();
> }

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).

> #3 is very interesting because I would have said that the "value" of a
>> ListView is the "items" list, not the selection. This is another reason I
>> am trying to refine the arguments, because I think there is something
>> interesting in that your proposal was that the "value" was the selected
>> item whereas my assumption was that it was the data model.
>> 
> 
> Good point. The problem comes back to the ChoiceBox (and ComboBox) I think.

ComboBox is likely to be different since it has an editable area that is distinct from the drop down -- I guess we can all go and check out the source code now that it is out there though :-)

>> What else, other than controls, would implement this proposed interface?
>> That is, is it really HasValue, or is it SingleValuedControl,
>> MultiValuedControl? This gets back to the need to tighten up the use cases
>> and arguments. Is the goal to make UI Controls more uniform for tools, or
>> is there a larger goal? For example, what happens if I have a layout
>> container that implements this interface. Is there some good reason why I
>> might want to do that?
>> 
> 
> Well, there's a possible example below with 'ToggleGroup'.

True, although it is "control-related". So it is safe to say it isn't just for controls, though so far the use cases are control related at least.

> Another possibility that is in the back of my mind but I'm not sure if it
> will work cleanly is a 'form' itself. In this case you would have a whole
> lot of HasValue fields binding to a bean, which in turn is exposed as the
> HasValue of the entire form (which is probably extending one of the Panes
> or MigPane).

Ya, that is good.

>> And if that is a use case that has to be supported, then we have to
>> evaluate the impact on the SelectionModel. That is, any attempts to mutate
>> the selection from the Skin code simply won't work (but that's OK if that's
>> OK, if you know what I mean). We (meaning all of us on this list) need to
>> evaluate what the impact is both semantically and in code. Typically we'd
>> put if(!isBound()) checks into the SelectionModel implementations so they
>> only change the selectedItem if it isn't bound to avoid the exception in
>> that case.
>> 
> 
> I think this one relates back to the fact that in List/Table/Tree the
> 'selection' is a visual GUI thing, more like 'focus', whereas in
> ChoiceBox/ComboBox the selection is a data thing, more like 'items'. Ideas
> for one seem to cause conflict with the other. Is there an argument here
> for ChoiceBox/ComboBox not using a selection model? Seems almost illogical
> that it wouldn't have a selectionModel but in reality it is semantically
> different to the normal selectionModel usage.

Well, we can't remove the selection model from the API, but I think you are right that there is a difference between what selection means in a ChoiceBox vs. a ListView / TreeView / TableView. 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.

Thanks
Richard