Now I just need to iron out an annoying issue with mouse-events not triggering properly.

I'm using the TornadoFX event-system with events fired in

setOnMouseClicked

etc. I take it that in it self shouldn't be a problem?

@edvin what if you specify a generic dirty behavior for the entire

TableView

?

And have a default one?

But make it overridable? Maybe you can use a corner flag by default for an edited cell? But then I can override it and say make the text red...

@thomasnield What about a dirty cell in non-edit mode, should we not touch that?

@permalmberg That should be fine 🙂

@edvin Ok, thanks

@edvin I think we can pursue that

@User uploaded a file: dirty state decorator.mp4

@thomasnield What do you think of this pattern?

Awesome!!!!!

This is exciting @edvin. My coworkers are going to be happy. Sharing this in an email now.

Is there a convention in JavaFX or ControlsFX for dirty fields? I think we established the flag as a precedent in TornadoFX right?

I think the flag looks great, and I'm asking my coworkers if they are cool with adopting this convention. That way we don't have to support custom formatting unless it would be easy to implement.

@thomasnield I've used this same convention in the validation decorators for forms, and I think it works pretty well. I've seen similar things in ExtJS and probably some other frameworks, so I feel it conveys dirty state pretty well. I've committed an initial version of the edit model, so you can try it out. All you need to do is call

table.enableDirtyTracking()

and the dirty columns should light up. To commit a row, do

table.editModel.commit(item)

or

table.editModel.commitSelected()

. Same for

rollback

of course. You can get to the dirty state for an item by doing

table.editModel.getDirtyState(item)

. On this object you can get the dirty columns via the

dirtyColumns

map. The keys are the columns and the values are the initial value of that column for the given item (that's the value used to do rollback). Remember that commit just clears the dirty state really, the values are written into your domain objects as you edit them, but rollback can revert that. I recommend also enabeling

regainFocusAfterEdit()

and

enableCellEditing()

on the TableView for a more pleasant editing experience. Also take a look at https://github.com/edvin/tornadofx/blob/master/src/test/kotlin/tornadofx/testapps/TableViewDirtyTest.kt for some advanced usage, including rolling back for columns, context menu and some default button actions. Let me know how this goes and if something is unclear. Tonight I'll first try to finish the docs for the Workspace, then write the docs for this feature and finally create a screencast to show this feature.

Please don't send me any feature requests today - you guys know I can't resist, but I really need to.. hehe 🙂

I probably didn't handle the dynamic context menu items properly in this example. It takes up almost all the code as well. Would like to investigate dynamic context menu items and how we can support it better (later).

@edvin so you dont want to think about an autocomplete combobox?

(hides under the desk)

@ron Ai ai aiiiii!

Here is a small sample with the editing integrated in a Workspace. I'd like to avoid needing to instantiate the TableView before hand, so I'll find a way to nice this up later tonight:

would be cool ™️

@User uploaded a file: Dirty Editing in Workspace

Notice the handy little

WorkspaceApp

🙂

@ron We need to do that at some point, but now I really really need to write some documentation.

I agree

and you need to look at the PR

@ron I will. I think I might have added some of that already, because I prototyped it locally before I commented on the PR. Will check after work 🙂

just fixed another conflict in it 😿