[REVIEW] Make controller instantiation customizable

[Greg Brown]

> Let's see if I understand the current logic how the include look up is
> done with a source like "/my/package/test/HeaderView.fxml".
> 
> My current assumption is that you are consulting the current Classloader
> to locate the file, correct?

Yes.

> The FXMLLoader is running in the JVM of the Tooling (in my case Eclipse
> but I guess it is the same for Netbeans) to e.g. place the preview next
> to your editor which naturally has no idea about the classpath found in
> your project.
...
> To make FXMLLoader happy I now need to construct an URLClassLoader by
> inspecting the projects classpath and redefine the
> Thread-Context-Classloader which has the draw backs outlined in my other

Shouldn't the IDE be creating a new class loader to load the preview anyways? It shouldn't be sharing the classloader that was used to load the IDE itself, since that would be a potential security hole (not to mention confusing, since the IDE code shouldn't be visible to the app code).

Also, with the addition of a setClassLoader() method to FXMLLoader, you wouldn't need to mess with the thread context class loader.

G