Subject: JavaFX dependency injection

Matthieu BROUILLARD matthieu at brouillard.fr
Wed Nov 25 16:01:28 UTC 2015


Hi,

This is not a new subject and I guess we already received answers in the
past on this list: JavaFX team does not provide any DI mechanism just like
core java teams do not provide any DI on java-se. What is provided is
"only" the possibility to hook controller factory (which allows already a
lot).

It has been for a while since people started to use DI for JavaFX:
- guice blog post July 2012:
http://andrewtill.blogspot.be/2012/07/creating-javafx-controllers-using-guice.html
- CDI blog post August 2012 :
http://blog.matthieu.brouillard.fr/2012/08/06/fxml-javafx-powered-by-cdi-jboss-weld_6/
- then Adam Bien provided Afterburner in April 2013 :
https://github.com/AdamBien/afterburner.fx
- you can even use another DI engine with afterburner :
http://blog.matthieu.brouillard.fr/2014/12/05/topgun-afterburner-finally-announced/

At AGFA, we used to have our own little CDI based framework to do DI, but
we stopped due to memory consumption of weld-client at that time.

As currently the only information provided by the controller factory is the
controller class I would suggest you to use that instead of a bean id.

And if you want a maintained javafx enabled DI framework, go with
Afterburner or Gluon Ignite.

Matthieu

On Wed, Nov 25, 2015 at 4:29 PM, Nitin Malik <nmalik1 at gmail.com> wrote:

> + mailgroup
>
> I dont think its non-standard. We have solved this by creating a factory
> that holds the bean id (and does a lookup when callback is invoked).
> Alternatively, to make the solution Spring-free, the factory can hold the
> controller object.
>
> Both these approaches work, but seem like a work around due to the
> restrictive API.
>
> I would like to get inputs from the Oracle folks on this.
>
> Nitin
>
>
> ---------- Forwarded message ----------
> From: Eugene Ryzhikov <eryzhikov at gmail.com>
> Date: Tue, Nov 24, 2015 at 8:22 PM
> Subject: Re: Subject: JavaFX dependency injection
> To: Nitin Malik <nmalik1 at gmail.com>
> Cc: openjfx-dev <openjfx-dev-bounces at openjdk.java.net>
>
>
> Nitin,
>
> Ignite makes use of standard JavaFX API, which provides only controller
> class as a parameter to a controller factory.
> I imagine you're proposing that access to bean id would be given in some
> non-standard way?
>
> In any case, Ignite is an open source framework, and any type of
> contributions are welcome.
> If you have an idea which can add to existing functionality, please send us
> a pull request. We’ll be glad to discuss it.
>
> Eugene
>
> From: Nitin Malik <nmalik1 at gmail.com>
> Date: Tuesday, November 24, 2015 at 8:03 PM
> To: Eugene Ryzhikov <eryzhikov at gmail.com>
> Subject: Re: Subject: JavaFX dependency injection
>
> Hi Eugene,
>
> This look promising, but I dont think it addresses the multiple controller
> scenario (#1) I outlined in my original mail.
>
> Specifically looking at this line
> <
> https://bitbucket.org/gluon-oss/ignite/src/c85197b33852b78b1a519dca2b1424314cb899fb/spring/src/main/java/com/gluonhq/ignite/spring/SpringContext.java?at=default&fileviewer=file-view-default#SpringContext.java-89
> >,
> the lookup is by class, not Spring bean. Are there plans to add support for
> this?
>
> Regards,
> Nitin
>
>
> On Tue, Nov 24, 2015 at 4:55 PM, Eugene Ryzhikov <eryzhikov at gmail.com>
> wrote:
>
> >
> > At Gluon we’ve open-sourced the framework called Ignite just for this
> > purpose.
> >
> > With this library, developers can use popular dependency injection
> > frameworks in their JavaFX applications, including inside their FXML
> > controllers. Gluon Ignite creates a common abstraction over several
> popular
> > dependency injection frameworks (currently Guice, Spring, and Dagger).
> Full
> > support of JSR-330 makes using dependency injection in JavaFX
> applications
> > trivial.
> >
> > For more information take a look at our blog at
> >
> >
> http://gluonhq.com/announcing-gluon-ignite-easy-javafx-dependency-injection/
> >
> > Eugene
> >
> >
> >
>


More information about the openjfx-dev mailing list