Proposal for improving nested controller interaction in JavaFX 2.2

[Greg Brown]

> Should we assume based on this proposal that there's no intent/interest in addressing the issues around FXML having such an explicit coupling with its controller (as discussed back in December: http://mail.openjdk.java.net/pipermail/openjfx-dev/2011-December/000175.html)?

As I've mentioned before, this is by design. What we're currently calling the "controller" is really just the backing logic for the view. As a result, there is an inherently tight relationship between the markup and the controller code, analogous (but obviously not identical) to .NET's partial classes.

One way to minimize the level of this association is by using a controller factory. By specifying the name of an interface or an abstract class as your document's controller, your factory can determine at runtime which concrete factory to provide for a given document.

Another option is to use an external controller, which I believe we had been calling a "presenter". The presenter would be responsible for instantiating both the view and the model and performing any necessary wiring. As far as I know, there's nothing within the current design that prevents you from adopting this model within your application.

My point is that, just because we're calling this construct a "controller" does not mean that it has to play the role of "controller" in your design. Unfortunately the term "controller" has been heavily overloaded, which leads to a number of, often conflicting interpretations of its meaning.

G