[REVIEW] Make controller instantiation customizable

[Greg Brown]

> Do you remember before 2.0 when Eamonn and I both wanted to invert the control and have the Controller create the FXML file rather than the other way around as we do now?

I think you could still do that, even within the existing framework. You could have your controller instantiate FXMLLoader and load the view. The controller could then extract the values it needed from the loader's namespace, and wire up any associations between the model and the view. In fact, this is how it originally worked in Pivot.

I think what may be missing is a way for the view to provide a typed interface to that controller. The namespace is inherently untyped, and it also does not provide an interface to any logic you might want to define within the view. 

But maybe this whole thing comes down to a terminology issue. What we're currently calling the "controller" could be viewed simply as the implementation of the view. Imagine that we called it "view manager" instead of "controller".  The "real" controller could be an external entity that simply communicates with the view via view manager. That way, we'd avoid the tight coupling between the actual controller and the view - and the view manager (what we're currently calling the controller) would provide a typed abstraction layer that the controller could use to talk to the view.
 
> We were thwarted due to the fx:include problem.

I think that may still be a problem. FXMLLoader has to instantiate other loaders to process the includes. That means that an external controller can't instantiate them. 

I think we'll need to give some serious thought as to exactly how we'd want to use includes with an externally-defined controller, and then figure out how we want to approach it. It could be something as simple as another callback that lets a listener know that an include is about to be processed, allowing the listener to create a new controller, which would in turn load the included FXML.

G