I'm currently migrating a rather smallish JavaFX p...

# tornadofx

[elexx]

I'm currently migrating a rather smallish JavaFX project to Tornadofx. At the moment the project uses Fuel to do some rest calls. I'd like to use Tornados rest client instead. The problem is, the project is split up in a "service" module and two frontend modules. One of them is a gui (JavaFX) and the other is a CLI frontend. The service module has dependencies to Fuel, the GUI frontend to the service module and Tornadofx and the CLI frontend only to the service module. From a software architectures perspective, I don't want to add Tornadofx to the service module, just to use the Rest and Json functions. This would result in Torandofx beeing packaged in the CLI client, which feels rather wrong to me. Would it be possible to package more then one artifact when building Tornadofx, to get for example a tornado-lib.jar (containing everything not directly related to FX) and tornado-fx.jar and maybe for backwards compat an tornado-all.jar. Is there anything like this on the roadmap? Would a PR be appreciated? Is this a stupid idea? Need feeback 🙂

[elexx]

Ok, I already feel a bit stupid for asking this question 😉 I read Rest.kt and Json.kt and found a lot of references to FX. Seems like this separation is simple not possible because Rest and Json heavily depend of FX data structures

[edvin]

A separation is still possible, but it would require more abstraction in other places. This is on the roadmap, when we adapt to JDK 11 or whatever version is current when JavaFX is finally decoupled from the JDK, we will revist. I would gladly accept a PR for this already, but as you've seen it's not a straight forward/quick fix 🙂

[carlw]

If the service layer is already defined in the shared project, why can't you just use that in your handlers and binding classes in TornadoFX? The TornadoFX code would only see your abstracted service functions which would also be used in the CLI interface. Your service layer can mediate between the Gson and your domain objects.

[carlw]

Another option that i've done (with plain JavaFX) is deliver an FX app that can operate in a "headless" mode

[Romanow]

@carlw how did you do headless mode?

[carlw]

i put everything in a jar and issued the cli or gui command through a pair of scripts (.bat and .sh)

[elexx]

@carlw yes this is what I'm currently doing while migration is in progress, but I'd really like to get rid of Fuel und Gson and replace them with the "service" utilities provided by Tornado, but without dependencies towards FX. I know that especially in Java <9 there is no difference at runtime because everything ends up on the same (only) classpath in a simple javase application. But I really like the idea of a hard separation of services vs ui code at least at compiletime. And putting Tornado as is on the compile classpath of my service module would enable a lazy/careless developer to create frontend-stuff in the service/backend module.

[carlw]

Why can’t you make the Fuel based service calls from TornadoFX?

[elexx]

I can, there is no technical problem. But having 2 dependencies (fuel, gson) replaced by a kotlin enhanced javax.json would be really nice to have. Unfortunately for me this enhancement is packaged together with a lot of heavily FX related stuff I don't want to be available in my service layer.