It's not much code, compared to JavaFX 🙂

I do think there is one problem with my onRebind solution namely if several views want to have there own rebind code

a listener would indeed be better if its a ‘traditional’ listener where all the listeners are called

Yes, that's what I was thinking as well.

I'm unsure what's the best approach here.. A list of functions of type () -> Unit or reuse some JavaFX listener interface...

ChangeListener<T>

is a candidate

The cheapest one is to add

onRollback

as a function. That would match

onCommit

, but you would need to write some code to use it.

that I would not mind (writing code) however is onRollback the right thing to do?

and it would not solve the problem if multiple views want their own code there as the

controller

is a singleton

Yeah, it's not the right solution for you. Trying ItemViewModel now.

.. and keeping your immutable trouble makers!

I really like the immutable objects, at work we usually use builders

They are good 🙂 I will look for more ways to accommodate them in TornadoFX

First change is to leverage ItemViewModel:

@User uploaded a file: Untitled

If an item is available, bind to the respective properties, if not, to the same default values you used in your fake/default Category. So we also change that in the controller to:

@User uploaded a file: Untitled

Next we tell the

CategoryListView

to push it's selected item to the

CategoryModel

on change:

@User uploaded a file: Untitled

(I also took the liberty of removing the redundant quotes for

text = it.title

😬)

And finally, we make

EntryView

listen to changes in the selected category and reload the list:

@User uploaded a file: Untitled

why the

items.setAll

instead of

items=...

It avoids the call to

observable()

. Here is an alternative approach:

@User uploaded a file: Untitled

We bind to

controller.selectedEntries

and update that directly in the controller instead:

Add this to the controller in that case:

@User uploaded a file: Untitled

It will yield the same result with a little less code, and a bit cleaner looking View. The same approach can be used when you swap to http calls, but then you don't need to reconfigure the View. If you are using the data in multiple places however, that's not a good way to go.

I am leaning towards the first style