@ron What do you mean get back? An event is sent to all listeners. If you want to send something back you gotta fire another event and that other thing needs to subscribe to that event.

then the jetty server thread should have a way of receiving it

@User uploaded a file: Untitled

this is how I wrote it in January

the server thread calls

String identifier = JfxdslKt.inputDialog("Browser identification", "name this browser", "browser id”);

and be gentle about this code, I just discovered kotlin 🙂

This is a perfect use case for the new eventbus actually 🙂 Try it!

you would have to have a non javafx subscribe method so basically bringing

component

outside of the ui

@ron There is.

FX.eventbus.subscribe()

Probably

FXKt

from Java though

this makes for tight coupling edvin, one of the reasons I was using guava is because it does not couple it to the ui implementation

I could make a complete new ui not based on javafx for example without having to change the eventbus

It's tight coupling to an event bus, same as with Guava? 🙂

guava is independent of javafx or tornadofx

in that sense its a loose coupling

using Guice and Guava decouples the UI and the eventbus from implementations

Then you can of course make a Guava bridge for those events quite easily.

Or just use the Guava eventbus for everything and make sure the subscriber calls

Platform.runLater

before updating the UI.

yes that is what I am doing now

I am making an interface that is used by the server thread (

keepassFX.service.BridgeService

)

You could subscribe to the Guava event and re-fire an FXEvent if you don't want to deal with that however.

the implementation is the tornadoFX side and the server only talks to the interface

now that is an excellent idea

I can put that in the interface implementation

Absolutely 🙂 I'm working on some small improvements to the eventbus now though, will post here soon.

good I will see if I can implement this

Here is an example of complete decoupling between controller and View. The View fires the

GiveMeData

event to say that it want's data. The Controller subscribes to this events and fires a

MyDataEvent

when it retrieves it. There is no need to think about threading, the data will be retrieved on a background thread automatically.

@User uploaded a file: Untitled

Since the

GiveMeData

event has

runOnFxApplicationThread = false

, a background thread will be spun of to deliver the event to the controller. When the controller then fires the

MyDataEvent

it will be delivered on the UI thread since the default for FXEvent is

runOnFxApplicationThread = true

. Could really use a sweeter word for that.

that is a very nice solution