[REVIEW] Make controller instantiation customizable

Richard Bair richard.bair at oracle.com
Thu Dec 15 17:11:03 PST 2011

On Dec 15, 2011, at 3:30 PM, Greg Brown <greg.x.brown at oracle.com> wrote:

>> 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). 
> Good summary. My 2 cents is this: FXML is fundamentally about instantiating and configuring objects - i.e. actual type instances. A string-based factory method is not consistent with this, nor is it strictly necessary. Class loaders can be used to perform string-to-class conversions, and factories can then be used to create class instances based on these types.

But what Dan wants to do is to go from a string to an instance using a DI lookup, not from a string to a class to an instance. How does the combination of ClassLoader + ControllerFactory solve that?

> Also, I still have yet to hear a concrete argument as to why this flexibility is even necessary. The design of FXML has been driven largely by real-world use cases rather than speculative ones. So if you have an actual use case that legitimately cannot be addressed by the current proposal, I'm very happy to continue this discussion. Otherwise, let's call it good and move on. We can always revisit it again later as we learn more about how developers are using FXML and the facilities it provides in their applications. Sound good?

What about the desire to load the controller using DI lookup?

Having (finally!) caught up on the thread I'm not certain we're doing the right thing by using ControllerFactory. Not that it is particularly bad, but I really like the param namespace idea. There is the problem of fx:include to resolve but maybe we ought to explore that before resolving this issue.


More information about the openjfx-dev mailing list