Could FXML use an interface and dynamic proxy for the passive view interface?

[Richard Bair]

I was just reading through another excellent Zonski post (http://www.zenjava.com/2011/12/11/javafx-and-mvp-a-smorgasbord-of-design-patterns/). I actually have never liked the idea that a GUI tool had to compromise best-practices for development (in fact, it seems that a good GUI tool would encourage and promote best practices), so the following got my attention:

================================================

So if FXML provides the controls and visual layout for our screen it is obviously a prime candidate for replacing the Java-based View’s we’ve defined in our previous options. This is good news, but it’s not all roses however. FXML has been designed with RAD tooling in mind (i.e. visual screen design tools), and seems to draw from backgrounds that are a little less rigorous in their design patterns than Java normally encourages.

As a result there are a number of areas where using FXML forces us to compromise on our pure MVP pattern. Here’s a few of them:

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

================================================

Which got me thinking. Can't we have FXMLLoader use dynamic proxies to allow the FXML file to refer to a passive view interface rather than a concrete controller implementation? That at least would allow for the "Passive View" design pattern to apply extremely cleanly. It still would mean, from the developer's perspective, 2 classes instead of 1 (an interface for the view and a controller which talks to that interface). I would have to think through this a little more (I guess the controller is still required, so that the FXML document has something to call for event handlers and such, but that the controller would only talk to the view via this Passive View interface rather than by grabbing nodes and binding things directly??)

Richard