Two ChoiceBox API additions
richard.bair at oracle.com
Thu Jan 12 11:23:31 PST 2012
I think that is less convenient though because there are a pile of pre-built converters for dealing with everything from dates to decimals. Being able to just reuse the known converters I think is a big win. Plus, it is "converting" it just isn't doing a two-way conversion, but that's OK.
On Jan 12, 2012, at 3:50 AM, Tom Schindl wrote:
> Might I suggest now when rethinking that passing a StringConverter is
> wrong and it should be CallBack<T,String>?
> So my suggested API:
> labelCallbackProperty: Callback<T,String>
> it simply isn't a a converter because you never use it for String => Object.
> Am 12.01.12 09:52, schrieb Tom Schindl:
>> Hi Jonathan (now with the list included),
>> Exactly this Text-Example made me think that the converter you are
>> setting here is something different!
>> The "converter" you are passing here is more a kind of label provider
>> (this term is borrowed from SWT/JFace). Naming it labelConverter btw
>> still leaves room for an imageConverter (though as discussed in the bug
>> Richard thought ChoiceBox is not the right UI-Control I'm still not so
>> sure about that).
>> I think the term converter should only be used if to* and from* are used
>> but that's maybe just me.
>> I'm not sure on this one now but couldn't one think about providing a
>> label converter to all structured controls (combobox, list, table, ...)
>> and then it suddenly once more gets a well known concept.
>> Am 12.01.12 09:15, schrieb Jonathan Giles:
>>> The reason why it is named 'converter' is for consistency across the
>>> API. The intention is that future controls may also have a converter
>>> that is a StringConverter. Already ComboBox has this API (but of course
>>> uses both toString(..) and fromString(..), which ChoiceBox does not).
>>> I can see your thinking behind the name - it is more specifically what
>>> it is - but at the same time I personally like the improved discovery
>>> (and lessened mental overhead) of using consistent API naming.
>>> What do others think?
>>> -- Jonathan
>>> On Thursday, 12 January 2012 8:40:41 p.m., Tom Schindl wrote:
>>>> Am 12.01.12 00:59, schrieb Paru Somashekar:
>>>>> The controls team is planning to add 2 new APIs to ChoiceBox control.
>>>>> They are :-
>>>>> 1. valueProperty : (getValue(), setValue() and valueProperty())
>>>>> The value of a ChoiceBox is defined as the selected item in the
>>>>> ChoiceBox selection model. The valueProperty is synchronized with the
>>>>> selectedItem, in that when a user sets the value property the selected
>>>>> item/index is updated accordingly. And when selection changes, the value
>>>>> property also reflects the change. This property allows for
>>>>> bi-directional binding of external properties to the ChoiceBox and
>>>>> updates the selection model accordingly.
>>>>> 2. converterProperty : (getConverter(), setConverter(),
>>>> Wouldn't it better named labelConverterProperty?
> 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
More information about the openjfx-dev