[REVIEW] Make controller instantiation customizable

[Richard Bair]

On Dec 13, 2011, at 3:40 PM, Daniel Zwolenski wrote:

> On Wed, Dec 14, 2011 at 10:00 AM, Tom Schindl
> <tom.schindl at bestsolution.at>wrote:
> 
>> Am 13.12.11 23:58, schrieb Tom Schindl:
>>> 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?
>>>> 
>>> 
>>> Now the correct reply to the correct mail. I'm using DI a lot but rarely
>>> use named things but I'd say 90% of the time I'm going with the
>>> interface name as the identifier so the Class-Object is fine at least
>>> for my DI uses cases.
>>> 
>> 
>> And for one who tries to write FXML-Tooling a simple key is a nightmare
>> e.g. to provide you with event callback proposals/validation, ... .
> 
> 
> True, and I agree with all of the above (except the stats of 10%, I suspect
> much higher - named look ups exist as key concepts in DI exactly because of
> the limitations of the more convenient but less flexible/powerful class
> based lookups).
> 
> BUT we *can* support the (supposedly) 10% case without doing any damage to
> the 90% case giving us 100% support! :)  i.e. doing the String approach
> doesn't cause anyone any problems and makes everyone able to achieve their
> goals: it is the more generic solution.

I'm not sure. Having the string be class based (explicitly either a class or interface) does in fact help the tooling situation because it means that the tool can identify what the controller is going to look like, and thus can provide binding from the UI to the controller etc. So even if there were a name-based lookup methodology, you'd still want some way of specifying the type of the controller if you were going to end up using a design tool.

But I am a little confused. In another email you mentioned the desire to not have this association between the FXML file and controller at all (ie: the controller loads the right view, not the other way around). But here you are advocating for the FXML file to load the correct Controller but use a name-based key instead of specifying a class or interface. I guess it is fair to say you want to be able to support both?

If you want to have name based lookup but still have some reasonable tool experience, you could add fx:controller-name or fx:controller-lookup attribute which would be the name based lookup, but still have fx:controller that specifies the class? Or you could have fx:controller-class as the class and make fx:controller the name or class based lookup.

> The only possible drawback is the fact that it is inconsistent with the
> BuilderFactory interface. I'd like to know the arguments for this
> consistency - what is the conceptual advantage to the end user in having
> consistency between Builders and Controllers? When you write a
> ControllerFactory, are you really thinking about the Builder or
> BuilderFactory API and getting annoyed that one is not like the other? I
> don't think I would.


I don't really see inconsistency with BuilderFactory as a big issue in this case either. Maybe it is because I see it as simply a Callback<String,Object>. Heck, really it probably should be a Callback since that is all it really is (I probably should have thought of that for BuilderFactory as well. Doh! Every other factory that I can think of in the platform uses Callback rather than having unique interfaces. One reason was to keep down the SAM interface explosion, another was to make it toolable. But I digress).

Personally I'm torn: having fx:controller & fx:controller-class (as proposed above) solves the cases well enough, but complicates the FXML side. Having fx:controller be a String is nice from the "factory" side in that you can load when, how, and what you want. But it makes tooling pretty much impossible without also adding fx:controller-class (or something like it).

Richard

Richard