> This is an implementation for the long standing issue of allowing to commit a > cell value when the focus is lost or the editing index (cell) changed. This > also contains [JDK-8089311](https://bugs.openjdk.org/browse/JDK-8089311) (for > better understanding the usecase with `TextField` cells, but we may split > this later on). > > TLDR > - > - New method `stopEdit()` > - Called when the editing operation was stopped OR the focus is lost. > - Both are situations where we can not guess what should happen. We do know > though that cancelling the edit without further customization is wrong. > Instead, developers can now decide what to do > - Examples: > - Editing operation can be stopped by the cell container, because the > developer called `edit()` with another index > - The user scrolled until the cell is reused > - Focus is lost because the user clicks on another focusable Node > - The default implementation will call `cancelEdit()` > - To be backwards compatible > - Because we do not know what value we should commit. A `Cell` does not > know what it means to be in the edit state. However, subclasses will know > that better. A `TextFieldTableCell` knows the value of the `TextField` and > can directly commit (or convert before) the text entered from the User. > - The existing `TextFieldXXXCell`s will utilize and call `stopEdit()`, and > they know exactly the value they can commit (the text) > > Behavioral Change > - > - Developers can override `stopEdit()` and call `commitEdit()` with the > desired value > - All `TextFieldXXXCell`s will now commit their value when the editing > operation was stopped > - They still cancel their edit when Escape is pressed > - Developers that subclassed `TextFieldXXXCell`s to implement their own > commit-on-focus-lost handling may need to remove their custom logic > - As outlined in the comments, this is probably a very rare case because > you can not access the `TextField` when subclassing it > - But if developers did indeed subclass it: All `Cell` operations, that > change the editing state, will check `isEditing()` before. So there might be > no problem at all and they will continue working, However, it is recommended > to adapt to the new `stopEdit` flow > - Developers can check out the `TextFieldXXXCell`s if they wish to adapt the > pattern to their own cell implementations > > - From my personal experience, in every project I saw a custom implementation > of a `TextFieldTableCell` (Note: Not using or subclassing the one from > JavaFX) that tried to implement focus lost on...
Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: - Merge branch 'master' of https://github.com/openjdk/jfx into focus-edit-stop - Merge branch 'master' of https://github.com/openjdk/jfx into focus-edit-stop # Conflicts: # modules/javafx.controls/src/main/java/javafx/scene/control/Cell.java - Merge branch 'master' of https://github.com/openjdk/jfx into focus-edit-stop - fix tests the real way + doc - review comments and test fix - Merge branch 'master' of https://github.com/openjdk/jfx into focus-edit-stop - javadoc - Improve behavior select signature, improve javadoc - make it final, improve docs - Merge branch 'master' of https://github.com/openjdk/jfx into focus-edit-stop - ... and 5 more: https://git.openjdk.org/jfx/compare/f844fd0c...d0de0d1f ------------- Changes: https://git.openjdk.org/jfx/pull/1935/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1935&range=09 Stats: 637 lines in 29 files changed: 477 ins; 43 del; 117 mod Patch: https://git.openjdk.org/jfx/pull/1935.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1935/head:pull/1935 PR: https://git.openjdk.org/jfx/pull/1935
