The current design for associating what I call a "controller" with an FXML file is as follows. If the root element of the scenegraph in the FXML is, say, an AnchorPane, then you create a subclass of AnchorPane that also implements Bindable, and you use that as your root element. So where the plain UI with no controller would look like this...

<AnchorPane>
    ...stuff...
</AnchorPane>

...adding a controller means defining a class, say MyController, like this:

public class MyController extends AnchorPane implements Bindable {
    ...
}

and changing the FXML to look like this:

<MyController>
    ...same stuff as before...
</MyController>

This is a problem for environments where the MyController class might not be available, and in particular for the Visual Tool. We want the VT to be able to operate even if the MyController class is unavailable, for example if it hasn't been written yet or doesn't compile.

Greg's proposed solution is to add a new fx:type attribute that is used to specify the controller class. Everything else is as before, including having the controller class inherit from a standard UI class. So the FXML would now look like this:

<AnchorPane fx:type="MyController">
    ...same stuff as before...
</AnchorPane>

(Presumably the value of fx:type would be subject to the same import logic as the names of elements.)