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

[Knut Arne Vedaa]

On 07.12.2011 03:09, Daniel Zwolenski wrote:
> 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.

I have come to agree as well. :) I think this is the cleanest solution.

I don't think you'd need getValue/setValue on the HasValue interface. 
They'd be available through valueProperty.getValue/setValue anyway.

However, I'm not quite sure if "valueProperty" is the best name, as 
"value" is used so much elsewhere. You'd have valueProperty.getValue, 
but also heightProperty.getValue etc. This could be confusing.

What about "dataProperty"? (And thus "HasData"?)

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

I agree. The selected item is the natural "data value" of a List etc. 
You'd then have a separate interface HasMultipleData with a method 
getMultipleData that returns an ObservableList of the multiple-selected 
items (e.g. forwards to MultipleSelectionModel.getSelectedItems).

However, one current complication is that for e.g. TextField the data 
property would be a Property, but for the "selected item" on e.g. a 
ListView it would be a ReadOnlyProperty. (Let's for now assume this 
problem can be solved and the selected item property can be writable. 
Otherwise you'd need a HasReadOnlyData as well.)

It'd also be nice to have a common interface for the entire items list 
of ListView and TreeView. They both have an itemsProperty that wraps an 
ObservableList, but no common interface. What about interface HasItems, 
with an itemsProperty field?

So, to sum it up, my suggestions:

interface HasData<T> {
   Property<T> dataProperty	
}

interface HasMultipleData<T> {
   ObservableList<T> getMultipleData
}

interface HasItems {
   ObjectProperty<ObservableList<T>> itemsProperty
}

(I'd consider naming them DataHolder, MultipleDataHolder, ItemsHolder 
instead, but that's cosmetics.)


Knut Arne