@edvin Checking this now…for background, I’ve had some good results implementing this diagram for clients (JavaFX, not yet TornadoFX)

@User uploaded a file: and commented: From following Microsoft link

This is an architecture similar to the popular Flux / React pattern for webapps

There is a V -> VM -> Model binding and imperative flow that behaves as one might expect. TextFields bind to properties. Buttons call actions down-the-line.

The M->VM (and occasionally the VM->V) use a notifications scheme to let components know there is change. Currently, I’m using these notifications (EventBus) as prompts for a component to make one or more Model calls rather than as a substitute for parameter passing.

MVVM works really well imho

The Model holds what the app believes is the recorded state of the data. The key to keeping this responsive is an asynchronous Task created at the VM level that prompts the Model to update. The VM will then be notified by the update.

Final note…I found an occasion where I had to pass a separate VM event up to the V to handle a SwingNode that couldn’t be bound with JavaFX.

@edvin Great video.... thanks for putting that one up. @carlw good suggestion on the format, it is really a great way to understand "best practices"...

@edvin i got a lot out of the video for my own TornadoFX programming. Thanks. This is a winning format. I think others will find it very engaging. Be sure to put #javafx in the hashtag when you tweet it out

@edvin … i just found your tweet

@edvin at 8:40 .. the reason for the event is in case that came from elsewhere. It’s a small app, but the VM is responding to the Model (subscribe) as though someone else had initiated the model update. I’d like to put something in place similar to WPF’s command binding. Right now, in both my JavaFX apps and the TornadoFX code I’ve been posting, I have the ViewModel responsible for the asynchrony. In WPF, it’s a separate entity called a command. Once you can break the command away from the ViewModel, it can be bound to actions just like the databinding of say a TextField. Then, the Command could be issued from a Scene KeyListener, a Fragment’s Button, a hide event from the View/Scene/Stage, etc. So, 8:40 can streamline the whole thing by returning <List<Customer>> from the Task, but the point is app-wide, consistent handling of the Model update rather than a combination of event passing and direct updating.

Also, the model update may force a view model to pull in more. Say a customer list changes. The viewmodel may also want to get a secondary list of something else. Although that secondary list may have also fired an event, the app should be able to consolidate things. Say an updated list of companies fires an event. The VM ignores the update. An updated list of customers fires an event. The VM retrieves both the customers and the previously-ignored companies.

@edvin - as always - great video! Can you post the before and after code for comparison purposes (perhaps add a link in the youtube description)?

@gtnarg: we were discussing making this a proper GitHub code review that could be looked at later

that would be good - just posting the updated code here would be helpful for side by side comparison now 🙂

Yeah the only room for improvement I see is post production stuff like displaying the window in the corner when Edvin references it

Thanks for the feedback! I'm building IKEA furniture at the cabin today, will follow up this afternoon :)

I'll blog about this, include Carl's feedback etc!

@carlw: Wonder if you just coined a new term for screencasts 👏🏻😜

@edvin When is the next release due?

@permalmberg Pretty soon I think. I'd like to improve

runAsync

and then release. There are two issues with

runAsync

right now. One is that you have no access to the

Task

instance while it runs, the other is a timing issue that nobody will probably ever notice (except for @Ruckus, who already knows). I'm unsure if we can make this without breaking the API, or introduce an alternative to

runAsync

.

Giving access to

Task

can be done within the current structure, but it would mean that

this

is

Task<*>

. If you try to access

valueProperty

, it would be

Any

instead of

T

. To solve that, I think

runAsync

would need to take a type parameter, and that sucks. Nobody wants to write

runAsync<Customer> { loadCustomer() }

.

There is some weird generics issue I don't understand with this task thing. If runAsync is defined like this:

fun <T> runAsync(func: () -> T) = task(func)

- then we don't need to supply a type argument, the compiler can infer

T

from the value

func

returns. However, if

func

operates` on something of type

T

, it suddenly requires that type parameter. Changing to

fun <T> runAsync(func: Task<T>.() -> T) = task(func)

is what I want to do.

@edvin so you don’t break user space…what do you think about an alternate runAsync() call signature that takes a Task? Then, the runAsync() method could create a Task off the passed-in Task and work with the rest of the fluent API (.ui(), etc)

@carlw I don't want the user to have to implement

Task

.

how about some other object that you can unpack in runAsync()? runAsync( () -> { status(”hello”, 40, 100) doSomething() status(”still going”, 60, 100) somethingElse()

}

where that object knows about a TornadoFX status method that it can use without a compiler error