[REVIEW] Make controller instantiation customizable

[Richard Bair]

>> I think we're crossing wires. I'm talking about the:
>> 
>> <param fx:id="someParameterInTheNamedParametersMap" />
>> 
>> not passing the String to the controller factory.
> 
> OK, thanks for clarifying. So what would be the use case for this feature? Where would I apply a <param> tag, and why?

I need a couple days to really think about it. The basic idea is that it provides an alternative way to populate the FXML namespace with things that could be referenced. So for example instead of having to add properties to a controller that your FXML then binds to, you could just create a <param> for elements in your namespace map provided on the FXML loader and then you could reference those from elsewhere in the document. It might even be a means to pass params to an fx:include, such that you could no longer have to have the FXML file create its controller. The idea strikes me as powerful but without adding much complexity to FXML, so I think it is worth thinking about.

>>> A developer will have to look a lot more closely at the Javadoc for setControllerFactory() to understand what a "callback" is in this context, and what call() will actually do. A dedicated interface is clearer, yet will be equally applicable to lambdas in Java 8.
>> 
>> I know the argument well. The same question has come up in multiple places in the platform. If we went with one-off interfaces, the interface names and method names would be much clearer and more specific. On the other hand, there would be more class files.
> 
> I'm not sure how much of an issue that really is in practice. As I recall, we use a lot of anonymous inner classes, which also add to the total class count. JavaFX is a framework, so in my opinion API clarity is much a more important consideration.

Understood. Certainly both opinions were expressed back when we resolved this issue for the rest of the platform. But its water under the bridge now, whether it was a good choice or a bad choice, it was a choice and it was made :-)

>> In the end, I think we need to use a Callback here. We've already faced and made this decision for the other parts of the platform, so it makes sense to be consistent here.
> 
> It would be consistent with other unrelated parts of the platform, but not with the BuilderFactory interface, which is used by FXMLLoader and is already defined similarly to ControllerFactory.

The difference is that BuilderFactory is intended to be implemented by random code. That is, every Builder in existence is supposed to implement it. ControllerFactory is completely different, it is a factory just like cell factory or any of the others, and those are all callbacks. Including the various callbacks in the web view APIs. It really should be a Callback to be consistent with the rest of the platform.

Cheers
Richard