Fair enough

I wonder if command chaining would be interesting...

maybe, but not in this context IMHO. this should be a lightweight Event -> Invoke Business Logic rather than a Composite Business Operation (chaining)

a chain-of-responsibility pattern (GoF pattern, not the prior discussion on WPF) could be useful toward the model layer

tornadofx could get into aspects at some point as well

Good points.

What about a Toast control then?

Question about binding data to a listview; If I have a ViewModel, is there as specific type of property it needs to be to properly bind so I can rollback, commit, etc? Basically I have add/remove buttons to add objects to a list view, and I want to bind that list to a property in my viewmodel. I have other properties wired up fine so I don't have to manually manage them, and was trying to do the same for the arraylist property with a listview.

@User uploaded a file:

Sirs, as someone drawn to JavaFX with Kotlin for a possible proof-of-concept at work; what's the concensus, does TornadoFX see them playing together very nicely or are there challenges?

@nyxcharon As long as the list is a subclass of ObservableList you should be fine. If not, can you post some code?

@chris-hatton I might be biased, but I'd say it's a perfect fit 🙂 TornadoFX provides a smoother, boiler plate free syntax on top of JavaFX, while taking care to never hide any of the JavaFX API's. Utilizing TornadoFX will not make JavaFX harder in any aspect. You can even choose to not use it for parts of your application, all though I can't think of a single reason for why you'd want to or need to. TornadoFX also provides a framework on top of JavaFX, with Views, ViewModels and even a Workspace if needed.

Also, for proof-of-concept you can't do much better than TornadoFX. You can have a polished UI up and running in a very short time, with very little code.

@edvin Thanks for the nod of approval 😀 looking forward to taking it all out for a drive.

Using Kotlin for Android at the moment; is superb.

@chris-hatton Great! If you get stuck or have any questions at all, please ask them here or create issues on GitHub. We are normally very quick to respond.

(And have done some JavaFX in the past so hopefully won't be completely lost)

Cheers.

Sadly the last JavaFX experience I had was the serious performance issues in SceneBuilder ... that had been introduced by Gluon (weren't apparent in the last Oracle version).

With Tornado; are people going down a pure programmatic/DSL route for UI's?

most of us go to the pure dsl route

I gave Gluon some very detailed reports and a project to reproduce it at the time but as far as I know it was never fixed... some issue with FontMetrics as I recall.

I think @carlw does stuff with fxml

I feel that the DSL gives you a much better overview than looking at the FXML. It's so much more concise and easier to refactor IMO.

Binding is also much easier, because instead of first declaring a field from the FXML and then doing the binding, you can create the ui element AND bind it in one go. Consider the following:

@User uploaded a file: Untitled

Just added a

TableView.requestResize()

function that will reapply the SmartResize policy. I also fixed a column header alignment bug.

@chris-hatton If your proof-of-concept is for a large project, you'll need something more in your software architecture than FXML and Controllers. In TornadoFX, there is a separation of screen state (the data on the screen) and record state (the app's view of the data). This helps greatly with reuse in the View layer. Also, there is a TornadoFX Event Bus that helps with the cascading updates problem by allowing the Model layer to emit notifications to interested components.

@carlw I'm most interested in producing a Desktop version of our headline Android Application. The business logic is, I think, quite cleanly encapsulated from a Manager+DataSources layer down

meaning we should be able to begin by modularizing those parts of the Android App, cleaning up any fallout, before taking that inner module and building an alternate JavaFX UI layer on top.