[REVIEW] Make controller instantiation customizable

[Daniel Zwolenski]

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.

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.