[REVIEW] Make controller instantiation customizable
greg.x.brown at oracle.com
Thu Dec 15 15:30:51 PST 2011
> 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.
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?
More information about the openjfx-dev