[REVIEW REQUEST] Add text property to ComboBox
jonathan.giles at oracle.com
Tue Apr 17 17:30:01 PDT 2012
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:
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
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
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
> What do you mean by "the desired API" ?
More information about the openjfx-dev