aha, NO

missed that (am new to Kotlin & Tornadofx; i.e. started last Fri)

long in the tooth Java + Swing dev (did I swear? 🙂 )

there's a lot of us here like that. I keep my Sun Certified Developer (Swing) diploma looking down on me as a painful reminder

I just wondered if the world had changed and took a look last week

Amazed how easy Kotlin and Tornadofx has made my life

reduced days to weeks to hours

The binding is really crucial. it's found in all current UI frameworks, even javascript stuff

IF I can get my head around some of the methods/functions available

no more listeners, manually setting UI controls

yes

This has some stuff you might use: https://courses.bekwam.net

I found myself jumping on the Global bus, but think I should be able to move away from that

global functions?

The EventBus

in tornadofx

The Swing models I produced had a LOT of listeners

the event bus is important to keep the control flow one-way. i use it as a back channel for model updates. I can initiate certain actions from the UI, say a "load" operation. when that load finishes, I can register for an event. the code that unpacks the event can update a class outfitted with javaFX properties and the UI then updates

otherwise, you end up on larger projects with set of fat Controllers that are coupled to both the View and the Model

aha, yes

so in my example, I have a particular screen/view that I add 'connectors' (for db and rest). When the user picks the connection they are using, I can use the event bus to get that view updated

if a new one is added or one is removed in the configuration section

both are separated by tabs

Regarding properties/observable stuff in tornadofx. Is it typical to just use the obserable types in your domain model? Doesnt that couple it to tornadofx? Right now i have a domain model free of tfx imports, that has a somewhat kotlinized version of ChangeListeners. Then i have a ViewModel type class that can take in the domain model and updates itself upon changes to the model. And of course the view is bound to the viewmodel as needed. does that sound right or am i making it more complicated?

@carlw where were you last night? 🙂 removeWhen is perfect! Form now does what want and is really simple to maintain

Can I ask another quick question?

sure.

Is there anyway to include a condition check in the removeWhen?

At the moment, I assign a Simple Boolean

that I set outside, which triggers. but actually, can I do an equals check on a string instead?