ComboBoxTableCell: Can we make it easier to use?

[Jonathan Giles]

Hi Scott,

The pre-built cell factories that ship with JavaFX are intended to 
provide convenience for the common use cases, and in some cases it just 
makes more sense to roll your own. Which use case you fall into I'm not 
quite sure, so the first thing to do is file bugs on the issues you're 
uncovering and we can try to make things more convenient for you. If 
that just isn't possible, then we can try to work out the best way 
forward from there. It certainly sounds like there is a combination of 
bugs and feature work to be done, so we can review again once the bugs 
are squashed.

Thanks,
-- Jonathan

On 19/07/2013 7:01 a.m., Scott Palmer wrote:
> ComboBoxTableCell is very awkward to use if you want to have graphics in
> the choices.
>
> There is poor support in general for setting the graphic for items in a
> combobox,  we have a StringConverter for the text part, but no
> "NodeConverter" for the graphic part.
>
> With ComboBoxTableCell it gets worse because the TableCell graphic is used
> to render the actual combobox during editing.  If you subclassed to
> override updateItem such as
>
>                      @Override
>                      public void updateItem(MyData data, boolean bln) {
>                          super.updateItem(data, bln);
>                          setGraphic(createGraphicFor(data));
>                      }
>
> (createGraphicFor is part of your implementation that returns a Node)
> You get graphics in the table cells, but cancelEdit will clear the graphic
> on you when it removes the ComboBox.
> You need to override cancelEdit as well with something like:
>                      @Override
>                      public void cancelEdit() {
>                          super.cancelEdit();
>                          setGraphic(createGraphicFor(getItem()));
>                      }
>
>
> That's just to keep the TableCell rendering the graphic outside of edit
> mode.  To get the graphics into the ComboBox used for editing you need to
> do something even uglier like:
>
>                      @Override
>                      public void startEdit() {
>                          super.startEdit();
>                          ComboBox<MyData > cb = (ComboBox) getGraphic();
>                          cb.setCellFactory(new Callback<ListView<MyData >,
> ListCell<MyData >>() {
>
>                              @Override
>                              public ListCell<MyData > call(ListView<MyData >
> p) {
>                                  return createMyListCell();
>                              }
>                          });
>                          cb.setButtonCell(createMyListCell());
>                      }
>
> Which uses undocumented knowledge of how these things work to know that it
> can get a ComboBox from the graphic in the first place.
>
> Just needed to subclass ListCell to get graphics into the Node seems like
> an over-complicated way to implement this concept.
>
>             new ListCell<MyData >() {
>              @Override
>              protected void updateItem(MyData data, boolean bln) {
>                  super.updateItem(data, bln);
>                  setGraphic(createGraphicFor(data));
>                  setText(data != null ? data.toString() : null);
>              }
>
> Would it be reasonable to extend the things like ComboBoxXXXCell to better
> handle graphics?
>
> The idea is to avoid having to override things in so many places:
> ComboBoxTableCell.updateItem, startEdit, cancelEdit, replace the
> cellFactory for the Combo which is itself buried inside the TableCell
> graphic, all in addition to setting the TableColumn cellFactory.
> Instead of just the one CellFactory that can be set on a ComboBox or
> ComboBoxXXXCell, such that the right thing just happens.
>
> The Cell editing process needs better documentation, but I already filed an
> issue for that.
>
>
> Regards,
>
> Scott