[REVIEW] Make controller instantiation customizable

Richard Bair Richard.Bair at oracle.com
Fri Dec 16 15:51:23 PST 2011

>> if we supported the alternative (named parameters declared on the FXML side) we might actually have a better all around solution
> As I mentioned in my previous message, I don't think this is either necessary or a good idea, since it would seem to violate the intent of IOC.

I think we're crossing wires. I'm talking about the:

<param fx:id="someParameterInTheNamedParametersMap" />

not passing the String to the controller factory.

>> FWIW, if we do go with the ControllerFactory, then we really should make it a Callback rather than a separate interface.
> While this would work from a strictly technical standpoint, I don't think it is the best option in terms of readability. It's pretty obvious to me what a ControllerFactory does - an implementation of this interface is obviously going to produce controllers based on a given type:
> public interface ControllerFactory {
>    public Object getController(Class<?> type);
> }
> OTOH, this is pretty ambiguous:
> public interface Callback<P, R> {
>    public R call(P param);
> }
> 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. Lambda's would work well enough in either case. On the other hand having a standard convention helps toolability. Just as having a special EventType helps, having a Callback type helps (see the recently pushed meta data, where Property, Event, and Callback are all top-level conceptual types).

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.


More information about the openjfx-dev mailing list