[REVIEW REQUEST] Add text property to ComboBox

[Alexandre (Shura) Iline]

I understand your take. And it is valid too.

However, if you follow this road, you follow it all the way through.

If you assume a string to be entered, make it visible through Javadoc.

And also, in such case, why not provide an access to the text control? 
There will be a text control - this is what you are saying. You would 
then allow ppl to access selection, like was mentioned in another 
e-mail, or anything else, such as caret position or whatever.

Now, I would expect such class to be named something like 
TextFieldEditingComboBox, but if you assume ComboBox is exactly that, 
that's fine.

Only one thing.

Similar to text property, I would expect a color property in case of 
selecting a color with an subclass of ComboBoxBase. Which brings me back 
to <code>T editedValue;</code>.

Ah, and another thing.

You somehow tie using ListView to using the ComboBox for strings. Why is 
this so? List view could show any type. It could show string 
representation of any type and also it could show graphical 
representation of any type, could it not? So, logically, there should be 
a ComboboxWithListView in between ComboBoxBase and ComboBox.

Shura


On 03/15/2012 12:17 AM, 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?
>>>