later tonight. i'm on a different machine now

sounds good 🙂 I have more client fires so I'll have to derive a bit, but I will be on early evening and very very late tonight

I will try to add a plugin later which will help you run the application directly from terminal using maven.

tornadofx is architecture agnostic, so you can have a one-way flow going from the view -> model components and then a back-channel, non-coupled communication path using the Event Bus

@carlw Do you happen to have a link to an example of doing things that way?

a javafx example is here: https://fxdocs.github.io/docs/index.html#_the_mvvm_pattern The two tornadofx things i did professional are unfortunately closed source, but i can put up a blog post during the holiday break. my next one is going to be on the drag and drop I posted earlier...might be able to tie the two together

@carlw in section

7.1.2 View

you say "UI field is bound bi-directionally to the ViewModel." I think @Sebastian is looking for something like React or Vue where the binding is one way. Perhaps I'm missing a key point.

mvvm is more like Backbone, isn't it?

it's one-way in that the ViewModel isn't called or set directly from the Model

@carlw Are there any plans of supporting some specific way? Like with the simplified way of creating normal properties.

My understanding of Flux-like architectures is that the UI sends changes to the data model, and that new state reactively propagates down to UI elements.

...some kind of StateStore

right

Yeah, a store class would take actions from the UI and, for instance, update the database. If all goes well the database informs about the successful change and the store updates the data model

And it is all async

It would be nice to have some support for that. I was thinking about a store class that you extend to be able to set the properties of the data model. And one could add functionality to simplify the automatic database updates and what ever else might come in handy, with a separate thread etc. But I don't know if that makes sense to add to something like TornadoFX.

you mean keep all the program state of a javafx app in a single store?

not necessarily

I've made Vue apps that have multiple stores

No, have different stores

we have something in TornadoFX that might help with what you're trying to do. Specifically, the Event Bus and the Command class. These are to help with async processing and to fend off any bi-directional loops that might develop in your app. as far as stores go, I usually have multiple model components that can be interrogated to get data. additionally, a command can be passed to these to refresh which is propagated to the view layer. the view layer can then choose to go back to the model components and pull fresh data (or ignore)

the project's mission is to add capabilities rather than frameworks. second-order projects that build off this would be a great idea. so, there is no official MVVM framework, but there is an Event Bus and Command class for example

Ok. I've seen the event bus, that part is covered. Is the command class for the actions sent via the event bus?

right now, it's a little thin (just an interface). It's mean to handle the asynchronous call so that native progress (javafx ProgressBar) can be communicate and to wrap up a JavaFX Task

i haven't done any flux programming, but i think what the tornadofx docs call a model can offer some store-like functionality (cache, emit events, etc)

The key thing in flux architecture (which isn't a framework either) is that no matter how or why the state changes, the UI simply reacts to that. There's no interrogation. View = f(state) at all times.

I think you're right about models being a way to do the store aspect of the architecture

FX is already based on observable data

yeah. don't forget about JavaFX too. things like rendering an HTML document don't map 100% to the desktop

I'll have to take a look at that then. Kind of my main concern is that if the data classes have public setters, it's easy to make a mistake somewhere. But I found a fairly simple way to avoid that that should do. Though lists are a bit tricky.