[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
consitent.
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.
Tom
--
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