I think you should get them from the model and place them into the new object

@edvin can you shed some light to @borboss question?

Ok. Just to clarify - I got the following class - data class LoginConfig( val loginName: String, val password: String, val additionalData: String ) As far, as I understood, ViewModel makes the copies of the properties, and implements the dirty pattern.

But what is the best practice of creating and passing properties to the ViewModel in this case?

My idea was to create some LoginPropertyBuilder object, that stores the properties isomorphic to the LoginConfig fields, and can perform validation and building for the new LoginConfig

But it seems to be quite a BoilerPlate solution

;-(

I haven't actually tried this myself, but I think something like this might work:

@User uploaded a file: Data class with view model

You initialize your ViewModel with the initial state of the Person. Then you call commit at some point when the user has changed the data. After that you can get the new person back by accessing

viewModel.item

.

the plugin should be able to generate that?

It is for sure more boilerplate than using mutable JavaFX properties, and we might be able to improve upon this structure.

@ron Absolutely. But since I haven't used it myself before I'd like to explore even easier ways to support this first.

@borboss Let me know if you try my suggestion above 🙂

Just a second! Try it in a few minutes

Great 🙂

@edvin The viewing works great!

@edvin but how to make it editable?

@edvin I merged my changes into fxlauncher. I want to look at the preloaderClass https://github.com/edvin/fxlauncher/issues/62 and then I think we could to a release of it.

@borboss we should make a demo application for that, the question comes up so every now and then

I will see if I can whip something this evenign

@borboss What kind of control do you want to make editable?

he was working with a normal data class

we dont have a demo with the

onCommit()

and data class

@ron OK, great! I'm not sure if we need to support the dedicated preloader functionality, it's pretty easy to add a preloader anyway. If you see that is's doable without too much fuzz it would be great though, but the preloader would need to be embedded in fxlauncher.jar I think?

no, its part of the actual program, called during the launch

at least the example he gives in the issue shows it like that

if he wants it from the fxlauncher itself we support that with the UIProvider (my opinion)

But the preloader for the actual app has then already run. Preloader is a thing you can use before the app is shown. When the launcher displays it's progress bar, the window for the preloader has already closed.

hmmz the way I read it he calls it in his own main