If he does, he's not using FXLauncher? 🙂

Well. I launch the program using class CSApp : App(MainCSView::class, Styles::class) { }

Actually I was trying to improve the example by Thomas Nield. So I wanted to use pure domain data classes. And all the examples with models in tornadofx that i saw use the mutable properties to edit the domain objects. So the simple variant as i see is to make some kind of builder classes with mutable properties in viewmodel, and create the immutable object in doCommit and then pass it to some comanion object method like addAnotherConfig(config: Config) : Observable<Config> and bind it with controller CompositeObservable

@edvin I will respond asking for more information

@ron OK, good plan.

@borboss What example was that?

@edvin https://github.com/thomasnield/rxkotlinfx-tornadofx-demo

@borboss Right, that one. I think you have all the building blocks now, but feel free to ask if you get stuck. I will start working on a small sample app using a database and immutable domain objects.

Mutable or immutable?

Updated my post.. hehe

I need to play a little with the keycap node first though.

@borboss This isn't a tornadofx example, but you can implement the same thing with a JavaFX-oriented ViewModel layer and a UI-agnostic, POJO Model layer. I regularly have a JAR of domain objects that I want to leverage across multiple views (JavaFX, web services, command line interface, Swing in one case) and there isn't a one-to-one relationship between what you put in a View and the Model. The support in TornadoFX for this design is to invoke model changing functionality through distinct methods and to provide model updates through the TornadoFX Event Bus. https://fxdocs.github.io/docs/index.html#_model_change_with_mvvm

@carlw 👍 I really like the agnostic POJO layer, it gives you the flexibility to do more with it

@ron I'll get a TornadoFX version out one of these days, maybe focused on an actual Java JAR linked up with a TornadoFX ViewModel.

I wonder what we can do to support it even further.

Basically that is my big problem with keepassFX, not only is it a POJO, they are immutable

The pattern I showed above isn't that bad though, but there could be more we can do.

what pattern was that? been cooking and eating and cleaning 🙂

@edvin I'd like to improve on the command/action mechanism which forms asynchronous calls in the ViewModel layer. They're in the ViewModel to provide the status updates that we discussed a few months ago. IIRC there was a tornadofx change to help. The commands (copied from WPF) should also contain some validation to determine whether or not there's enough info to run them. Ex class SaveCommand : Command() { fun okToRun() : Boolean { ... } fun runAsynch() : Unit { ... }

I like that. I feel like we should consider coroutines for this.

Do you envision menu item adapters etc?

Me too...i'm not sure how, but coroutines are used in WPF

more than adapters, I'm looking for "command binding". ex MenuItem().disableProperty( command.okToRun().not() )

i know there's no action property (yet), and also MenUitem().actionProperty().bind( command.run() )

We could even support

menuitem.bind(command)

.

That would bind both the disableProperty and the actionProperty in one go.

Inside a

menu

builder you could do

add(command)

and it would be added as a bound menuitem.

Provided that the command has a text property as well.

If commands are registered with the workbench or something else, they could also describe their accelerator/key combination.

dont go too far too fast