[REVIEW REQUEST] Add text property to ComboBox
Alexandre (Shura) Iline
alexandre.iline at oracle.com
Thu Mar 15 01:15:25 PDT 2012
On 03/15/2012 12:00 PM, Tom Eugelink wrote:
> I think I agree in essence with Jonathan on his reasoning, I may want to
> push it even a nudge further. It is a fact that the usage of letters
> (and other symbols) will stay one of the most used data entry methods.
> The other entry method being gestures, whether made by mouse, finger or
> motion (I'm swiping everything onto a single pile; click, drag, swipe,
> shake, etc). All other inputs all translate to these two, for example
> speech recognition equals text. So, as I see it, after parsing the raw
> events, we end up with either text or gestures (this is the syntax layer).
I would argue that you really should be talking about keyboard and
gestures - not text and gestures.
But that aside, you really are assuming having the editor to be a text
component of some sort. For entering color I may, for example have a
container with three text fields (RGB). Can I not do so?
> In the next layer these text and gestures must get a meaning (this is
> the sematics layer). Is a text a number? Is a gesture a list scroll?
> Jonathan's text property hooks at the syntax level (where the input has
> not been validated so to speak), the reasoning below is at the sematics
> level (where a text already has been identified as a number). AFAIK
> there is a call back for the semantics level (at least there is in my
> spinner and I think I copied that from ComboBox).
> So since we know that text is a main input method, there would be IMHO
> no harm in adding the text property to the base class. There is a good
> chance a color picker also allows for entering a HTML color code (and if
> not, it simply is unused).
> Independent of this discussion, exposing the actual TextField from the
> skin remains a bad idea. Maybe some one will be using a TextArea. So the
> TextInputThingy is a good solution, and as said, that can be on base
> level class IMHO.
> On 2012-03-14 21:17, Jonathan Giles wrote:
>> I'm not sure that I agree with this line of thought, but I'm also
>> quite likely wrong.
>> My thinking is that on ComboBox, the text property should exist and be
>> of type String, not T. I think this because ComboBox is a
>> specialisation of the ComboBoxBase class, which I foresee as being the
>> logical point of extension for future ComboBox-esque controls (e.g.
>> Colour Picker). For this reason, the ComboBox specialises in showing a
>> TextField for editing, and a ListView for selection, and there is no
>> escaping the fact that all input is String-based. The text property
>> essentially represents the 'raw' text prior to commit.
>> In other words, I think the current patch on RT-19589 is correct for
>> the text property use case. Future use cases will be handled in the
>> same way - by adding API to ComboBox directly. The text property would
>> be added to ComboBox, not ComboBoxBase, so future combo box
>> implementations can go ahead without the text property clogging up the
>> -- Jonathan
>> On 15/03/2012 12:28 a.m., Alexandre (Shura) Iline wrote:
>>> Judging from the javadoc, combobox component could handle different
>>> types - not only String. I could redefine the skin, I assume, and
>>> have any editor within it, so, there may not be a text field to get a
>>> text from in the first place.
>>> Should the "text" property be of a type T and named somehow else?
>>> On 03/14/2012 04:53 AM, Jonathan Giles wrote:
>>>> Hi all (yet again),
>>>> A quick one this time: http://javafx-jira.kenai.com/browse/RT-19589
>>>> I'm wanting to add a text property to ComboBox, to allow for people to
>>>> easily set the text in the ComboBox without committing it to being a
>>>> value. More importantly, this also allows for developers to extract the
>>>> content of the ComboBox TextField without having to have end-users
>>>> the Enter key to commit the text into the value property.
>>>> Without this end users who want to support Enter-less committing of
>>>> content have to reach into the ComboBox skin, which is not particularly
>>>> Any thoughts?
More information about the openjfx-dev