[REVIEW] Make controller instantiation customizable

[Daniel Zwolenski]

Maybe we should put all the future "what more could FXML be" discussion
aside - let's spawn that one off to another thread so you can move forward
on this one. So just looking at your original request for review of the
factory mechanism:

In general the factory looks great, except there are some options on how
the fx:controller value gets passed to the Factory (and consequently the
URL resolving):

1. *getController(Class)* : The FXMLLoader resolves the class from the
fx:controller attribute and passes this Class into the factory.

2. *getController(String)* : The FXMLLoader just passes the String exactly
as it is defined in the FXML straight to the factory. The factory is
responsible for resolving the class. By convention the FXML should use a
'classname', exactly as it is now but this is enforced by the factory, not
the FXMLLoader.

3. *getController(Class, String)* : The FXML splits the string on a colon
(:) and resolves the first part to a class (exactly as in option 1). The
optional second part is passed as the String directly to the factory (much
like option 2).


Option 2 is the lowest common denominator and is the most
flexible/extensible solution. i.e. Option 1 and Option 3 (and many other
options) could both be supported by option 2 (i.e. the parsing logic just
moves into the factory).

All 3 options use the convention that the controller is a well-known class
in order for tooling support to work. In option 2 however this is enforced
only by the factory so a custom factory could choose not to enforce this.
This allows for future extensions (e.g. the fx:controller is actually a
reference to a groovy script, or is a URL to a controller class not on the
current classpath, etc). It also allows those using FXML in a non-standard
way (such as myself) to hook in and hijack this method for custom usage
sacrificing tool support (this could be viewed as a 'pro' or a 'con' - you
decide).

Option 1 and 3 introduce the need for special class loading support in case
the factory wishes to load the controller from one or more external
classloaders as the FXMLLoader will first need to load the class. In option
2 this is avoided, all classloader specifics can be handled internally
within the factory (where I feel they belong). If we go for either option 1
or 3 we probably need some more discussion on the classloader mechanism.

Option 2 has been noted to be inconsistent with the BuilderFactory API but
this has also been identified as not overly important by Richard.

I obviously vote heavily for option 2. Over to the floor and/or Richard I
guess.

Regardless of the decision, in general, I am very happy that we are getting
controller factory support and appreciate that the community was listen to
on this. Nice work.