[REVIEW] Make controller instantiation customizable

[Greg Brown]

> The view manager is useful, but I think it will be simple code mostly delegating to the controller or to the view. Being simple, I think a view manager can be better by being declarative (for avoiding bugs and allowing automatic persistency).
> 
I don't personally think we'd want to go down that route. Part of the view is already declarative - that's the static part that gets defined in FXML. The other part is procedural - that's the logic that gets defined in what we currently call the controller. Trying to replace the procedural part with something declarative seems like it would be really unwieldy and inflexible. OTOH, I don't think there is anything in the current design that would prevent you from doing that, if you wanted to.

Given the notion of repurposing the current markup+controller as simply the implementation of the view, and introducing a new controller abstraction that sits outside of that view, I'd like to understand what, if any, value the addition of the <?param> PI might still offer. It seems like its original purpose was to help facilitate stronger typing of the FXML namespace, but since we can already get that (and more) by using the FXML controller as the interface to the view, it doesn't seem like there is quite as strong a case for adding param support.

FWIW, I think this particular issue is actually independent of FXML. I could just as easily construct the UI hierarchy for my view in code, or using some other kind of builder. I'd still want to encapsulate access to it via some kind of "view manager" so the controller didn't need to be aware of the internal details of how the view is implemented. The FXML controller is just a convenient way to implement that.

G