[REVIEW] Make controller instantiation customizable

[Greg Brown]

> Any chance we could have the method take the string exactly as it is defined in the FXML, rather than have FXML create a class and pass that in? I'm thinking of two scenarios for this: 1) the class being loaded is via a different classloader (i.e. my controllers and FXML are coming from a repository somewhere and loaded on demand via a custom URL classloader),

Two reasons why I'm not sure this is the right solution:

1) The current design is consistent with the BuilderFactory interface, which also takes a Class.

2) Since FXMLLoader uses the current thread context class loader, your app has control over how the class will be loaded.

> 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 know this is probably not inline with your view of it all, but I would love for a way to provide a default controller so if none was specified in the FXML, the loader would use this.

Can you summarize a use case for that here? Controllers and FXML documents are pretty tightly coupled. I'm having a hard time envisioning what a "catch-all" default controller might do.

> Can we have the FXMLLoader throw an exception if it tries to set a non-null @FXML field. That would prevent any confusion around double-binding when a controller is shared. I'd prefer this over the less obvious binding to last possible field. This would also stop a newbie error I see on the forum every now and then: they new their fields and then do stuff to it in the constructor not realising it gets created by FXMLLoader. An exception would sort them out sooner. 

Seems reasonable.

> 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.

G