On Fri, 15 May 2026 23:03:04 GMT, Marius Hanl <[email protected]> wrote:
>>> And most of the time there is not much configuration needed, and hopefully >>> even less after this PR. >> >> +1 >> >>> 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. >> >> Exactly. In swing, it's delegated to the model if I recall correctly, but >> in FX we just have an observable list of items. So the only place the >> application can implement a per-cell editability is to override >> TableView::edit(). Guess it is possible, just not elegant. >> >> >> >>> 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)); >> >> >> This looks like a great idea! We have event system, and we should use it >> for this purpose as it allows to >> - inform interested parties about changes >> - allow the interested parties to veto a particular action >> >> So I guess this is also possible with the existing APIs, perhaps we should >> consider making it a built-in functionality? > >> This looks like a great idea! We have event system, and we should use it for >> this purpose as it allows to >> >> * inform interested parties about changes >> * allow the interested parties to veto a particular action >> >> So I guess this is also possible with the existing APIs, perhaps we should >> consider making it a built-in functionality? > > This would get a +1 from me. This is very useful. I used that often for e.g. > saving. So I have 20 columns with different `setOnEditCommit` handlers > (usually calling a setter, but could be more complex) and one on the table > with the `ExtendedTable.commitEvent()`, where I just get the item and save it. @Maran23 sorry this PR got auto-closed second time. would you mind re-opening it again, I'll make sure someone in our team reviews it. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1935#issuecomment-6636432722
