ComboBox and cell factories
jonathan.giles at oracle.com
Wed Apr 18 15:16:08 PDT 2012
Today I have a new topic I'd like opinions on:
The ComboBox control, being the specialisation of the ComboBoxBase
class, is a Button/TextField and ListView specific control, as I
mentioned yesterday. The basic issue is that there was an oversight when
developing Combobox for 2.1. The issue is that, whilst it is great to
support a cell factory in not just the popup listview, but also in the
button area itself, it is often the case that you want the
representation to be different. Currently, one cell factory is used for
both the Button and the ListView.
The jira issue has screenshots demonstrating where this is an issue in
the HTMLEditor control. Basically, you don't want to render a font name
in the button area, and you don't want the font size to be shown in the
button area (as large font sizes will grow the height of the button).
So, to resolve this, we need to support having a way to configure a
separate cell to be shown in the button area and / or to use the default
cell in the button area (whilst using the custom cell factory for the
listview). The question comes down to how obvious we want the API to be.
Some options I can think of include:
1. Adding a separate ComboBox 'buttonCell' property of type
ListCell<T>. If this property is set, it is used for the button
area. If it is not set, we should use the default 'toString' cell
(rather than using the ComboBox.cellFactory to generate a cell, as
we do now). If a developer wants the same rendering in the button as
the ListView, they will now need to create a cell from the cell
factory they have set in the ComboBox.cellFactory property, and
manually set that in buttonCell property.
2. We can make the API less obvious by setting some property in the
ListCell used in the button (from the skin). This property can then
be watched for in the custom cell instances, drawing as appropriate.
The place to set any property would be in the properties map, rather
than adding new API to ListCell.
My preference is strongly towards approach 1, but I would be interested
in hearing your feedback, on these options, as well as other options. I
would like to fix this for 2.2, but time is short so I would appreciate
your feedback as soon as possible.
More information about the openjfx-dev