[REVIEW REQUEST] Add text property to ComboBox

[Tom Eugelink]

(Nagging kids about some breakfast they want, so I forgot one argument. ;-)

As a parallel: in the compromise where the font was exposed, why wasn't the whole control in the skin exposed?

Tom



On 2012-04-18 07:25, Tom Eugelink wrote:
>
> I think this is a point where there is no absolute true or false. Your reasoning is sound, the question is how hard this "separation of concerns" should be. In his email two days ago Richard mentioned there were other compromises, so this could be one as well.
>
> On the other hand; if you are exposing the TextField, there will be other usage of that as well. People will not only react to text changes, but start doing other stuff with the TextField field. It will set a way of working, not how JavaFX wants things to be. Why would we expose the full TextField instead of only what actually is needed to solve the problem?
>
> My gut keeps saying no.
>
> Tom
>
>
>
>
> On 2012-04-18 02:30, Jonathan Giles wrote:
>> Hi all,
>>
>> Now that I'm back to work and feature freeze for 2.2 is nearing, I'm hoping to get a resolution on this topic.
>>
>> The basic premise is covered here: http://javafx-jira.kenai.com/browse/RT-19589
>>
>> Simply put, there are often requirements to access the editor component of the ComboBox control, to do things such as reading and writing the current input (without interacting with the ComboBox value property), showing prompt text, setting or clearing text selection, etc. This is being especially driven by the Scene Builder team, who are finding the ComboBox control limiting for them.
>>
>> The ComboBox control is a specialisation of the ComboBoxBase control. ComboBoxBase is display-agnostic (both in terms of the editor functionality, as well as what happens when show() is called), whereas ComboBox is defined to be the most commonly-required ComboBox design: a Button/TextField that pops up a ListView when clicked. This means that conceptually it is totally fine for ComboBox to return the TextField/TextInputControl via some 'getEditor()' (or similar) method.
>>
>> The concern expressed in earlier emails was that this was leaking the skin implementation out into the public control API. I would argue that this is not necessarily true - it is leaking it out into the ComboBox public API definitely, but not into the ComboBoxBase API. This means that future implementers of ComboBox-like functionality who are not wanting the editing functionality to be TextInputControl/TextField-based would be unwise to extend ComboBox, but they should be totally fine extending ComboBoxBase, where there will be no 'getEditor()' (or similar) method.
>>
>> What are peoples thoughts? Can we wrap this one up by simply exposing the TextField/TextInputControl, or are there concerns with this? Also, if we are to expose one, I'm tempted to expose TextField rather than TextInputControl...
>>
>> Thanks,
>> Jonathan
>>
>> On 16/03/2012 9:33 p.m., Jerome Cambon wrote:
>>>
>>>
>>> On 3/15/12 8:42 PM, Jonathan Giles wrote:
>>>>
>>>> On 16/03/2012 2:32 a.m., Jerome Cambon wrote:
>>>>> Exposing TextInputControl is exactly what we need. At least it is the purpose of the Jira which is the base of this discussion.
>>>>> We have concrete requirements in Scene Builder for this.
>>>>>
>>>>> Our use case is the following :
>>>>> - we have a set of editable ComboBox in a VBox, with initial values set
>>>>> - for convenience, once modified, we directly type TAB to go to the next ComboBox
>>>>> - its value is selected so that we can directly enter the new value without having to remove the old one
>>>>>
>>>>> This seems to be a very common use case...
>>>>>
>>>> I can see the point of exposing the TextField, but as with others in this thread, it does leave me feeling uncomfortable. My inclination is to provide the desired API directly on ComboBox.
>>>
>>> I agree to not expose TextField. I'm speaking about TextInputControl here.
>>> What do you mean by "the desired API" ?
>>>
>>> thanks
>>> JErome
>>>
>>
>
>
>