[REVIEW REQUEST] Add text property to ComboBox

[Tom Eugelink]

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).

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.

Tom





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 API.
>
> -- Jonathan
>
>
> On 15/03/2012 12:28 a.m., Alexandre (Shura) Iline wrote:
>> Jonathan,
>>
>> 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?
>>
>> Shura.
>>
>> 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 press
>>> 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
>>> pleasant.
>>>
>>> Any thoughts?
>>>
>