let me paint an example

Inject them?

imagine I were creating a DB frontend app. the first screen you see upon opening it is just a couple fields asking your for a hostname and port, maybe a username and password, and a button to connect. you connect. You now, presumably have a DbConnection object that the rest of the app (or its controllers) will need. how do I get this DbConnection into each controller?

maybe I'm trying to ask: how do I inject() something that can't simply be looked up and and built via reflection magic?

That form would be some kind of ViewModel-backed thing that gets your values. If your controller injects that same view model, then it will get the values you save from the form.

Or, when you hit your "connect" button on that form, the result could be calling a method in your controller that takes the values as arguments

ok, interesting

i was thinking to construct the DbConnection from those parameters and just have that available to the controller

but either way i think i'm just hung up on the idea that the DbConnection the controller has should be a val, rather than something settable

i guess it doesn't have to be that way

injecting the same ViewModel is interesting

@kevinherron @kastork is onto the right track - gather the input values in a ViewModel, and store the resulting connection in for example a

val connection = SimpleObjectProperty<Connection>()

inside a

DatabaseController

or something similar.

@edvin I had a mail asking for a possibility for fxlauncher to ask whether the user wants to update or not and start the not updated version of the user says no

when I am home I will post the mail into an issue, next week I am returning to normal programming

most of the terrible puppet stuff is slowly getting done

this whole puppet project will take another 2 months to be completely done, but the hard work seems to be coming to an end

@ron Sounds like a nice feature.

@kevinherron If you're working with a ConnectionPool or DataSource, those would be good vals (or finals in Java) since they would never change for the life of the app. In this case, you'd call ds.getConnection() when you needed a Connection, possibly retrieving a live one from a pool. @edvin's suggestion for a Connection container SimpleObjectProperty also works. If you bring in a ConnectionPool object, inject it that so that it's available everywhere, you'll also get some added value if the Connections could ever timeout because you can validate the connection prior to returning it.

I like that, @carlw. It would also be a good idea to shut down the connection pool correctly by overriding

stop

in your App class.

you'll end up building one yourself even if it's for a single item

@carlw thanks for the suggestion. the DB idea was just to help explain, but I understand what you’re suggesting

in this case I am talking about building a “Client” object on the first screen that would then be used for the remainder of the app lifetime

@kevinherron that connection container / client container val would work in a lot of cases. i just did something for a RESTful client that needed to retry a 2nd or 3rd server if the first one failed. I may be working on a JMS one next week that would do this too. The DI makes the shared object available to all components that need it

yeah, I was just confused at first about how to initial construct the shared object so that it can be injected everywhere

in fact, i’m still slightly unsure, because in the Controller it’s going to be a

lateinit var client: OpcUaClient

and the initial screen will be responsible for setting it

not sure if that’s the correct way to go about it

@kevinherron What is OpcUaClient? Maybe you can show us some code and we can suggest improvements?

OpcUaClient

is the object I’ll need to share across that app that I can only construct once I have the details from the first screen

I’ll share some code this weekend, once I’ve actually written it… right now I’m just trying to get a conceptual idea of what I’m going to do…