On Fri, 15 May 2026 17:45:32 GMT, Andy Goryachev <[email protected]> wrote:
> Sort of related question, since I don't have much experience with editable
> virtualized controls. One thought keeps nagging me while looking at these
> changes: why do we make decision to cancel or commit at the cell level?
> Should it be rather done on the control level, since it's the control that
> has the full picture?
>
> Maybe we should consider a sort of editing policy property which would allow
> the application to specify what to do in each particular case (focus lost,
> ESC, ...), or even based on the content of the cell if that's a part of the
> requirement? So, instead of the application overriding the cells, it would
> simply provide a policy or use one of the standard policies?
>
> Does it make sense?
Well it kind of works like that already. Just that the concerns are separated
in:
- `TableView`, provides the items and columns
- `TableColumn` need to decide what to do on start, commit and cancel
(`setOnEditCommit(..)`)
- Typically, you call a setter with your new value on commit
- `TableCell` need to know what it should do on edit start, commit and cancel
(e.g. show a graphic like `TextField`, show a `ComboBox`, a Popup, ....)
- It also need to decide when to cancel (e.g. Escape) or commit. If focus
loss commit is not desired, it does not need to be implemented
- Some Cells may do not even care about Escape or focus loss, like a
`CheckBoxTableCell`, which can just be clicked (will also never be in the
editing state really).
- Inform the column then about the event, but might also need to know how to
convert e.g. a String into type <T>
The API makes sense and that is also why cell implementations like the
`TextFieldTableCell` exist, so not much code is needed in order to create
tables with everything that is usually needed. So most of the time, you don't
need to override anything.
So any API on `TableView` level might really work - too many different things
are involved. And the cells can be vastly different. It is hard to find a
common point here.
And most of the time there is not much configuration needed, and hopefully even
less after this PR.
> Should it be rather done on the control level, since it's the control that
> has the full picture?
With that said, there are things that are very very hard to actually find out /
implement. Yes, the control should have the full picture, but has not. For
example, there is no easy to find out what cell is actually editable. The table
knows if it is editable and if the columns are, but has no idea about the
`TableRow` or `TableCell`. Very similar that it does not know what the
`TableCell` does, beside edit, cancel and commit.
Also the table does not get a notification event that a commit happened, so it
does not know the full picture in this regard either.
That is why at one point implemented something like that in my columns:
Event.fireEvent(tableView, new CommitEvent<>(this, tableView,
ExtendedTable.preCommitEvent(), item));
commitValue(item, newValue);
Event.fireEvent(tableView, new CommitEvent<>(this, tableView,
ExtendedTable.commitEvent(), item));
That would be indeed helpful.
-------------
PR Comment: https://git.openjdk.org/jfx/pull/1935#issuecomment-4463682049
