Thanks for your input, @edvin. I'm going to run some errands, but will see any additional input that you have when I return. Thanks!

@javafxpert Super, ttyl 🙂

Interesting: https://github.com/edvin/tornadofx/issues/573

I think there should be an easy way to create a new model based on data from a ViewModel.

@edvin uploaded a file: Untitled

A simpler approach would be to temporarily swap out the item for the current viewmodel, but that has side effects because it will trigger change events on itemProperty.

What about looking at this from the validation side? Maybe a lifecycle addition such as a preValidate or postValidate phase called before the commit, etc

Seems like an optimistic submission would be the most performant instead of doubling up on each server side call as a matter of policy. But there could be a longer running postValidate for some more validation?

Say the case where the client just doesn’t know enough to get the job done

@carlw Good point, I think that makes for a better API as well.

The reporter of the issue probably would want a

postValidate(item: T): Boolean

callback or something, so I might still just leave that function in there though.

Coroutines might help too

But the more generally useful callback might be

postValidate(): Boolean

and he could call

itemWithCurrentValues

if he needs to.

Yeah, I was just about to mention it because now comes the issue of the ui thread vs background work.

Put an await in between each synchronous validation

We can just as well do it without coroutines though.

Will you try to synchronize the tasks with a locking object? Today’s validation is 100% synchronous, right?

@carlw I'm not sure, but I think it's worth trying to implement something better for the existing validation functions as well.

For a long running validation, I’ve used a task that synchronizes on a wait/notify with a timeout. Coroutines would be a lot nicer. Maybe you can add the api lifecycle now and then see how the current version of coroutines looks? That should just allow an await to be put in the new postValidation method

I'll play with this when I'm back from a little trip tomorrow 🙂

Another long standing/hard to debug error fixed: https://github.com/edvin/tornadofx/issues/570 🎉

Hi everyone! Soo, you seem to just use the normal read/write properties for data classes. Can’t that lead to some issues? The flux idea (similar concepts are available), where there’s only one class that can update the data, seems more structured. That way the whole encapsulation also makes more sense to me. I’ve written some code with read only properties (objects and primitives / not sure about lists and maps), but what’s your view on it as (more) experienced programmers?

@carlw you awake my friend?

yeah. i’m east coast time, so it’s not early

using the FXMLLoader in javafx itself is still the best way to load fxml files?

my stupid son refuses to switch tornadofx and kotlin for his school projects 🙂

(and he is reading this, he is also too stupid to join this channel and ask for himself)

he should join. my son is going to intern with me next summer and he’ll be on. we have a tornadofx project that i think we can pull off in the field of biomedical engineering (his degree)

ROFL Pedro did a year of biomedical engineering at uni , then he got smart and switched to ICT

but back to FXMLoader (non tornadofx), there are two ways I work with this 1. placing the load close to the stage code. This is working with the FXMLLoader class alongside the Scene and Stage 2. putting the FXMLLoader code inside of a Controller’s constructor