nice

ask the table which rows are dirty 🙂

@ron Yes, something like that 🙂 Would be handy, maybe even with some custom decorators to show the dirty state and a way to extract all dirty rows.

nice I see two use cases

1) respond when a row goes dirty (something like

onDirty()

and the one above tableview.getAllDirtyRows()`

This could be done much cheaper than the ViewModel, since we can hook onto the edit commit events of the tableview.

and even do a rollback of all the changes in all the rows?

Meeh.. that would require more work. If it's only detecting dirty rows this is very cheap to do. Once to start with rollback and stuff like that it will be more involved and more resource hungry.

It would require a specialized

TableViewEditModel

I think.

I dont mind that

Hehe, it would be the most sexy solution for sure. But I have to say stop some time to be able to do the release, and we've added so many features that I'll never be able to catch up with documentation or even ever finish the guide if we keep going like this.

well release 1.5.10 and keep 1.6.0-SNAPSHOT for this stuff?

I think we'll go straight to 1.6.0, but I don't know if I want to use much time on creating a TableViewEditModel now. Docs are more important. I'll find a nice solution for Thomas's use case though.

@edvin no rush, I'd have to refactor whatever you came up with into existing applications anyway. I just think there has got to be better ways to manage it. I often use Rx to push formatted Node controls as column values which feels a bit like overkill and probably uses memory.

@thomasnield I have some ideas 🙂 Do you need to rollback or just detect dirty state?

@thomasnield And do you want to track dirty state per column or just per row?

Dirty state per column and row, as well as rollback. That would eliminate so much boilerplate at work.

@thomasnield Sweet! We'll make it happen! Got to decide if we should release 1.6.0 first or not. Will finish writing the Workspace documentation tonight, then try an initial

TableViewEditModel

and see how it goes 🙂

@edvin @thomasnield - I have the exact same use case as Thomas - this would be a killer feature for me. You are correct that it would probably be resource hungry - but that's a side effect of the use case...

Okay sounds good, take your time so we can get this right. I'll put some work hours towards it. Oh. And it would be great if there was commit() functionality too.

@gtnarg @thomasnield We'll make it happen. I absolutely see the value in this myself, I'll probably use it in the CRM.

I'd like to make this possible without having to use the ItemViewModel though.

It will most likely require that the items in the table have correct equals/hashCode implementations.

Of course regarding equality. So does my TableFilterControl. There is some overlap with the ItemViewModel, so maybe extract an interface or something. Either way, they are different.

Do you use JavaFX properties for the TableView column values, or do you have POJOs?

I almost always use JavaFX properties if they are editable

Sweet, it will make things easier.

Yeah I wouldn't prioritize POJO/POKO support. I guess that could come later if people want it

Ok, then we have our scope.

@edvin - my domain objects already exist and unfortunately are POJOs - so unfortunately it's utility (for me) without it would be greatly decreased