[REVIEW] Make controller instantiation customizable

Tom Schindl tom.schindl at bestsolution.at
Tue Dec 13 14:43:35 PST 2011

Am 13.12.11 22:53, schrieb Richard Bair:
>>> and 2) the developer chooses to forgo tool support and instead uses a 'name' as the controller attribute in the FXML - this name could then be used to lookup the controller in a DI factory/module (this allows for multiple instances of the same controller class to be used, just configured differently, which is not supported in the proposed mechanism).
>> Seems like it might be an edge case (i.e. falls into the "10% case" vs. the "90%" case").
> I'm not sure, all it takes is one popular framework that wants to make use of it and it becomes a 90% case :-). I think with the DI frameworks, having a named lookup is probably pretty common?

My vote would have been also on the String instead of a Class but
because the Builder API also works like this I think we should stay

I agree with Daniel that changing the Thread-Context-Classloader feels
really dirty.

The whole Class loading thing was also a problem to OSGi where there's
nothing like a global classpath and so I had to set and reset the
context classloader.

Might I suggest that you add the possibility to set a custom classloader
to FXMLLoader (FXMLLoader#setClassloader(Classloader)) which is used for
the class look up?

IMHO this would solve the OSGi and Daniels use case.


B e s t S o l u t i o n . a t                        EDV Systemhaus GmbH
tom schindl                 geschäftsführer/CEO
eduard-bodem-gasse 5-7/1   A-6020 innsbruck     fax      ++43 512 935833
http://www.BestSolution.at                      phone    ++43 512 935834

More information about the openjfx-dev mailing list