[REVIEW] Make controller instantiation customizable

Greg Brown greg.x.brown at oracle.com
Sat Dec 17 11:38:39 PST 2011

I was just reviewing an earlier post on a related thread ("Could FXML use an interface and dynamic proxy for the passive view interface?"), and I think that the "external controller" proposal actually addresses all of the original issues fairly well:

> - You have to specify your presenter (which FXML directly calls a controller) implementation inside your FXML. This breaks a fundamental concept of MVP, that the view and presenter should be decoupled as much as possible, and means you cannot reuse your view with another controller without copying the whole view again.

By externalizing the controller (which I guess we should just call presenter, to avoid confusion with the current definition of controller), this becomes a non-issue.

> - You can’t use interfaces for your presenter (as per option 2 above), since FXML needs a concrete class to instantiate.

As I mentioned earlier in this thread, you can actually use interfaces - your controller factory can simply return an appropriate implementation of that interface. Controller field injection will still work, and you'd get even more flexibility if we added support for property-based injection.

However, to reiterate - this is a non-issue if the presenter is externalized. You can create and configure it however you like.

> - The FXML loader instantiates the controller in internal code that we have no access to, so to make this work with a DI framework you have to jump through hoops to get setter injection to work (and constructor injection doesn’t work at all).

This limitation is resolved by the addition of the ControllerFactory interface, but again it is a non-issue if you are using an external presenter.

> - In order to access the fields of your view within your presenter (i.e. to show data on the screen), you have to expose the fields directly to the presenter using @FXML annotations. This means your presenter ends up knowing far too much intimate detail about your view.

By using the FXML controller as the interface to the view, we preserve the abstraction and don't need to reveal any unnecessary details to the presenter.



More information about the openjfx-dev mailing list