Two ChoiceBox API additions

[Richard Bair]

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.

Richard

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.
> 
> Tom
> 
> 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.
>> 
>> Tom
>> 
>> 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(),
>>>>> converterProperty())
>>>> 
>>>> Wouldn't it better named labelConverterProperty?
>>>> 
>>>> 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