> 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. > - Those two 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, or the user scrolled until > the cell is reused > - Default will call `cancelEdit()` > - to be backward compatible > - because we do not know what value we should commit, even if we want to > (subclasses will know that better) > - `TextFieldXXXCell`s will utilize and call `stopEdit()`, and they know > exactly the value they can commit > > 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 or the focus is lost > - Developers that subclassed `TextFieldXXXCell`s to implement their own > commit-on-focus-lost/editing operation stopped may need to remove their > custom logic. Since all `Cell` operations that change the editing state will > check the editing state (`isEditing(9`) before, their might be no problem at > all. > - Developers can check out the source of `TextFieldXXXCell`s if they wish to > adapt the pattern to their own cell implementations > > --- > > <details> > <summary>More about the API, Considerations and Follow Ups</summary> > > API > - > - Instead of calling `cancelEdit`, every cell now calls `stopEdit` when the > focus is lost or the editing index changed. The default behavior is > cancelling the edit, but developers can now override the behavior and allow a > `commitEdit` instead > - There are multiple 'events' that can lead to a editing change. Every change > will now call `stopEdit`. > It is therefore the responsibility of the developer to decide, when it makes > sense to actually commit the value instead of cancelling it. > This decision was made as the behavior is manipulating the editing index, but > you as a developer can as well. Therefore, we do not always know what > intention led to a change of th...
Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: - 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 - change the way focus is shifted - Fix problem when initially selecting a cell - Simplify focus listener - Merge branch 'master' of https://github.com/openjdk/jfx into focus-edit-stop - focus edit ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1935/files - new: https://git.openjdk.org/jfx/pull/1935/files/21a4cf00..a2b7639f Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1935&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1935&range=04-05 Stats: 66398 lines in 479 files changed: 25377 ins; 19516 del; 21505 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
