[REVIEW] Make controller instantiation customizable
Tom Schindl
tom.schindl at bestsolution.at
Wed Dec 14 06:31:11 PST 2011
Hi Greg,
First off all I agree with the addition of passing a custom classloader
and the ControllerFactory the system gets much more
configureable/customizable.
I don't expect a normal user to get in touch with this proposed API. It
is meant for Library Developers like Daniel, Roman, ... who want e.g.
use other strategies e.g. to bind the controller fields and e.g. get
away with the controller instatiation done by FXMLLoader completely.
Whereas I would only overload the loadClass-method they would overload
the probably all of them. At least to me this API would work exactly
like you stated: "making simple things easy and difficult things possible".
Without knowing the code in FXMLLoader I think my proposal would simply
require you to factor out the Field/Method-Binding Code in a class one
can subclass (yes DefaultWiring is a class) and customize it.
Anyways for my current use cases the ControllerFactory with the
possibility to define a custom ClassLoader is prefectly ok. I just
thought we could address all problems with one generic concept. Unless
Daniel thinks this design would help him to achieve his use cases I'll
not push this idea forward.
Tom
Am 14.12.11 15:16, schrieb Greg Brown:
> This seems pretty complex to me. Again, the design philosophy we have tried to apply here is "making simple things easy and difficult things possible". You can do quite a few "difficult" things with a custom class loader and the proposed ControllerFactory interface. For example, if an include needs a different class loader from its parent, your custom class loader can handle that by composition.
>
> G
>
> On Dec 13, 2011, at 10:27 PM, Tom Schindl wrote:
>
>> Hi,
>>
>> Having thought about this even more I think classloading is not the only
>> thing people might customize, the same goes for event and field binding,
>> all what I'd summerize below resolving and wireing.
>>
>> I think we could address some of Daniel's requests and the classloading
>> with one delegating class people could customize.
>>
>> It could look like this:
>>
>> FXMLLoader f ....
>> f.setWireing(new DefaultWireing() {
>>
>> @Override
>> public Class<?> loadClass(String fxmlFileId, String name) {
>>
>> }
>>
>> @Override
>> public ElementBinder getControllerElementBinder(
>> String fxmlFileId,
>> Object controller, // might be null
>> String elementId) {
>>
>> }
>>
>> @Override
>> public MethodBinder getControllerMethodBinder(
>> String fxmlFileId,
>> Object controller, // might be null
>> String methodName,
>> Class<?>... arguments) {
>>
>> }
>>
>> @Override
>> public String loadIncludeFile(
>> String fxmlFileId,
>> String includeFilePath) {
>>
>> }
>>
>> });
>>
>> The reason I think FXMLLoader#setClassloader(Classloader)) is not enough
>> is that one could include a child fxml-Files who might need a complete
>> different Classloader.
>>
>> To identify a fxml-File I'd suggest to add something like fx:componentid
>> but this is not a must and we could also pass the FQN-Name of the
>> fxml-File to identify it.
>>
>> Tom
>>
>> Am 14.12.11 00:50, schrieb Greg Brown:
>>>> 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?
>>>
>>> This might be a good alternative. Let me give that some thought.
>>>
>>> Thanks,
>>> G
>>>
>>
>>
>> --
>> 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
>
--
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