[REVIEW] Make controller instantiation customizable

[Daniel Zwolenski]

What about one of the following in the FXML (your choice which one);

<HBox fx:controller>
<HBox fx:controller="">
<HBox fx:controller="default">
<HBox fx:default-controller>

Results in the ControllerFactory being called with a null controller class and then my factory has the job of deciding what the 'default' controller is in this case. No change needed to the FXMLLoader API. 

Richard, this is me bet-hedging. This is the path of pragmatism (what am I likely to get in the short term). 

On the path of idealism (what would I like in the long term) we have these two scenic drives:

1. The FXML declares named/typed variables that the loader can supply.

2. The FXML 'implements' a view interface. Tooling would generate the interface instead of the controller class. 

Both need fleshing out in more detail if there is interest (ie. Possibility of actually being implemented)?

If FXML was open sourced, I would build option 1 (even if it was just for my own internal use). It is the most flexible solution. Simple and effective with no one design pattern enforced (even the word 'controller' is gone).

Option #2 is perfect for a specific design pattern (ie interface based MVP), which just happens to be my preferred pattern, but this is a core jdk toolkit. I don't think it should be geared to any one pattern but should empower as many options as possible (the fact that the current design is geared only to tooling is an example of not keeping the design open, hence the 'MVP compromise'). So:  option #2 would be good for me, but I don't think it is the best thing for the JavaFX community and that's what we're all about here right?

The good thing about #1 and a sign that it meets the keep-options-open philosophy is that you could actually build #2 on top of it (as an open source 3rd party project - which is where 'specifics' belong). At the same time it can be used along side the current approach without breaking it (it is just the namespace extended, plus expressions for 'callbacks'). You could also implement everyone of the design patterns outlined on my blog as well as most other 'classics' I can think of. 








On 15/12/2011, at 3:51 AM, Greg Brown <greg.x.brown at oracle.com> wrote:

>> at first glance, I don't see any reason why we couldn't add a setController() method in addition to getController().
> 
> I just prototyped this, and there is one potential issue - the controller is currently reset to null every time load() is called. We'd have to remove that code so we wouldn't inadvertently blow away any caller-provided value. The downside is that, if the FXMLLoader instance is reused to load another file, the controller won't be automatically cleared, which could be confusing. So I'm not sure that making the "controller" property mutable is such a good idea.
> 
> We could go with Daniel's original suggestion to pass the controller to the load() method, but it seems a bit strange to me. We could do it - but maybe you could try working with ControllerFactory and setClassLoader() to see if they might meet your needs first?
> 
> G
>