[REVIEW] Make controller instantiation customizable

[Gaja Sutra]

>> 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.
I think we will always have need of possible Java code, if logic of this 
view manager is too much complex.

But I hope that, in the future, by replacing some simple parts by 
<?param?> or by declarative state machine, the Java view manager can 
finally become empty and removed in simple cases. State machines, like 
SCXML, have graphical tooling [1] and I think it can be much better is a 
graphic designer can specify without even one line of Java code or some 
other script language, that if you click "Play" button, then the video 
start playing.

[1]: http://commons.apache.org/sandbox/gsoc/2010/scxml-eclipse/

Currently my biggest hope in reducing size of view model is having 
<?param?>, because this is probably the most simple to be added 
(comparatively to state machine) and the most frequent use case (for me).

> 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.
For me FXML is a declarative DSL (domain specific language) for 
constructing a part of scenegraph:

  * allowing better specific tools than Java code (Scene Builder) and
    splitting of job between programmers and designers.
  * deleting a big chunk of Java code without high logic density (the
    method constructing this UI hierarchy).

Having <?param?> allow multiple arguments to this constructor of object 
represented by FXML. Would it be better to always use only one tuple for 
all arguments (the only one FXML controller)?

By example, did you prefer using a constructor with multiple arguments:
|new String(byte[] bytes, Charset charset) {...}|
or a constructor with an unique argument, a tuple (class with public 
fields in Java is similar):
|new String(ByteArrayAndCharset uniqueArg) {...}
public ByteArrayAndCharset {
     public byte[] bytes;
     public Charset charset;
}

|What do you think is the most readable code?
|String string = new String(bytes, charset);|
or this code:
|ByteArrayAndCharset arg = new ByteArrayAndCharset();
arg.bytes = bytes;
arg.charset = charset;
String string = new String(arg);

:-)
|
> 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.
Yes, but when I create UI hierarchy in Java code, I can give multiple 
objects as arguments to my method building the UI hierarchy.