[REVIEW] Make controller instantiation customizable

[Richard Bair]

>> and 2) the developer chooses to forgo tool support and instead uses a 'name' as the controller attribute in the FXML - this name could then be used to lookup the controller in a DI factory/module (this allows for multiple instances of the same controller class to be used, just configured differently, which is not supported in the proposed mechanism).
> 
> Seems like it might be an edge case (i.e. falls into the "10% case" vs. the "90%" case").

I'm not sure, all it takes is one popular framework that wants to make use of it and it becomes a 90% case :-). I think with the DI frameworks, having a named lookup is probably pretty common?

>> Similarly I'm not so keen on the null resulting in default behaviour as it could lead to confusion as well.
> 
> This behavior is also consistent with BuilderFactory, so I think that defining a different behavior for ControllerFactory might actually be more confusing.

Personally I don't mind having a null return value mean "do the default thing". I assume that any exceptions raised by the ControllerFactory would end up being caught within the FXMLLoader, such that if you have an error condition instead of returning null you would just throw a new RuntimeException of some kind (maybe IllegalArgumentException or IllegalStateException or some such).

Richard