This article has a little on MVVM which I've used ...
# tornadofx
c
This article has a little on MVVM which I've used in the C# world. I've maintained a few plain JavaFX apps and they suffer from what I call "fat controller syndrome" where the controllers become coupled to both the view and the model, breaking any semblance of encapsulation. https://courses.bekwam.net/public_tutorials/bkcourse_tornadofx_mvvm.html My designs lately -- for the larger JavaFX stuff I do and the smaller TornadoFX apps I support -- have been to establish a one-direction object graph whereby commands go from View -> ViewModel -> Model. I then use notifications or the Event Bus as a back channel for when the frontmost layers need to be aware of some data that's just come in.
g
Thats funny, I have the opposite problem. I like FXML, but there's no templating system, so if you think of a standard list view --eg the github issues page-- the most natural fit to my mind is for your view code to express a kind of template, where you define the static wrapping view, and then something like "produce one of these for every item on the page". FXML has no mechanism to do this. The result is that we create an outer "controller" (view-model), and then inner view-models per line item. The result of this is pressure to make views really small, thus we get lots of files, and reduced value from SceneBuilder (which is IMHO the whole goddamn point of FXML). I'll be interested to see how tornadoFX handles this problem. I'd imagine that will all the power of kotlin it'l be a breeze, but I wonder how polluted with domain logic it'l get
Regarding MVVM itself, I'm familiar with it, and I dont really have a problem with the architecture, I more have a problem with what would be idiomatic MVC/MVP/MVVM in tornado FX.
s
My understanding is tornado tries to be agnostic to the patterns, just guves you the tools to use whichever.
While a developer could certainly mix view and model code together with tornado if they wanted to, i think you'll find that its relatively easy to keep doing a similar approach, you'll just have a View or Fragment class instead of FXML. and of course... You CAN keep using FXML too if you really wanted