[REVIEW] Make controller instantiation customizable

[Greg Brown]

> Currently the fx:controller in the FXML is used for two things:
> 
>   1. defining the *API/contract* between the Controller and the FXML and
>   2. providing the *lookup/instantiation* details of the controller
>   implementation

Yep.

> The ultimate goal would be to move #2 (which breaks decoupling) out of the
> FXML (and into a DI factory), while still keeping #1 (which gives us nice
> tool support).
> 
> I personally could work with one of two options:
> 
> 1) *Default controller*: No reference to the controller is specified in the
> FXML at all. My factory passes the controller instance into the FXMLLoader
> when it calls the load method and this controller is used for everything
> within the FXML. I lose tooling support but I have decoupled my View and
> Controller.

OK, now I understand what you mean by "default controller". I thought you meant that you wanted FXMLLoader to automatically create a controller for a document even when one wasn't specified using the fx:controller attribute. I didn't think that was a good idea, since not all documents require a controller. 

However, at first glance, I don't see any reason why we couldn't add a setController() method in addition to getController(). This way, how the controller is defined and constructed would be entirely up to you. Would that work?

I think we'll still want to support the ControllerFactory interface, though. A setController() method would work for a root document, but not for includes, since you don't create the FXMLLoaders for those. It seems like that would be OK for your use case - since you want to create the controller yourself and manually associate it with the view, you probably wouldn't want to use includes anyways. But for callers who do want to use the fx:controller attribute, we should still provide a way to hook into the controller instantiation process.

G