no, they set themselves up through subscriptions. it's every component for themselves

So in my view model, I have to subscribe to changes in the model.

I thought binding did that for me

that's a little too coupled. you don't want every textfield character to update the model

I'm not making changes by typing, some background process is updating the data store

there may be some cool tornadofx feature that lets you build a ListView on a REST, but the apps I work on usually have varying cardinality between model and view

RE: background process. even better. the model is updated out of the blue and the viewmodels need to react

but they don't, at least not when binding is the only mechanism in play

that's where the EventBus comes in. let the background process do its work async and post a notification to subscribing viewmodels when done

Yes, I understand an event driven model of changes. I'm just misunderstanding how binding works. My expectation was that observable data structures would be, er, observed by things that are bound to them.

that's the View <-> ViewModel interaction. The View just has a bunch of declarative bindings

And I'm just suggesting one architecture that i've found successful. there's nothing stopping you from filling an ObservableList from a background thread, but you'll need to make sure that those add() calls take place on the FXThread

@carlw I can go back to using events if that's the idiomatic way to architect javafx apps.

you don't get a whole lot of architecture from plain javafx. i watched an app struggle that used the FXML / Controller model. Controllers got to be huge and needed to be shored up with the 'ol Business Delegate pattern

i'm seeing a lot more mvvm in other communities. i just saw a post on react + mvvm for the swift language

@carlw Interesting so basically you use the EventBus as your Controller like so? View <--> Viewmodel <--- EventBus --> Model

Do you have an url to the post

no, ViewModel -> Task (maybe command?) -> Model Model -> EventBus -> ViewModel(s)

the new command thing may push the command relationship into a view binding, cutting out the middleman ViewModel which in my apps lately simply delegates

But all your business logic is in the Model or Model classes right?

as much as possible. sometimes presentation logic and business logic can be blurred and winds up in the viewmodel

I would expect the Status cells to update periodically as

validateSetup

progresses.

watch the ui{} which is a Platform.runLater. you expect the status to be updated after the verify() and the some() call, but runLater doesn't mean run now

but they never update. Are you saying

ui

does not put the update on the application thread?

it does. but i once tried to interleave long-running methods with UI updates and found the UI updates weren't called when I expected

I've put breakpoints on the assignment statements, and they are running

ok...a few versions ago so maybe it's better

but again, those assignments don't propagate to the view.

what i usually do -- and coroutines may clean this up significantly -- is use a set of nested Tasks and update the UI in the succeeded method. The succeeded method also calls another Task. This is very ugly, but i've had some head-scratching behavior trying to stuff platform.runLater into my call() method (of the JavaFX Task)

within my Tasks, i use updateMessage and updateProgress and that seems to be very reliable