Could FXML use an interface and dynamic proxy for the passive view interface?

[Richard Bair]

>>>> Which got me thinking. Can't we have FXMLLoader use dynamic proxies to allow the FXML file to refer to a passive view interface rather than a concrete controller implementation? That at least would allow for the "Passive View" design pattern to apply extremely cleanly. It still would mean, from the developer's perspective, 2 classes instead of 1 (an interface for the view and a controller which talks to that interface). I would have to think through this a little more (I guess the controller is still required, so that the FXML document has something to call for event handlers and such, but that the controller would only talk to the view via this Passive View interface rather than by grabbing nodes and binding things directly??)
>>>> 
>>> 
>>> See RT-17268 did I get you wrong?
>> 
>> I think this covers the ControllerFactory -- ie delegate controller construction to the developer -- but is separate from dynamically generating an implementation of a Passive View interface.
>> 
>> Cheers
>> Richard
> 
> You are right but to seperate the controller from the view this is most
> important one.
> 
> I'm having a hard time making up in my mind how you would envision your
> passive dynamic view interface to work. Could you show us/me some pseudo
> code?

Well, the idea is that I might define:

public interface MyView {
    public StringProperty nameProperty();
    public ObjectProperty<EventHandler<ActionEvent>> submitActionProperty();
}

And then in my Controller, I would just work with this interface. I wouldn't use @FXML or talk to the view directly. Instead, there would be a way for the FXMLLoader to inject an implementation of this interface to my controller via the constructor (or whatnot). This part I haven't ironed out, because in theory you just want:

public class MyController {
    private MyView myView;
    private Customer customer;

    public MyController(MyView myView) {
        // create or get the customer
        // bind the customer to the nameField of the myView
        myView.submitActionProperty().set(new EventHandler<ActionEvent>() { ... });
    }
}

The FXML file would maybe have been designed by name convention to match the MyView so that the FXMLLoader knows how to associate the property defined in the MyView with a concrete property in the FXML file. This part I'm not sure of and would have to think more (I don't think you want to annotate the MyView because that sort of defeats the purpose of separation of concerns).

Anyway, it was an idea that was not fully formed. The so-called "Passive View" wants to have such an interface, and so my thought was whether there was a way to use dynamic proxies to create an implementation of a view dynamically that would then map onto an FXML file. It isn't something that helps tooling or anything from the FXML perspective, but allows the controller to work with a UI without any preconception of the language or control or whatever at work in the view.

Richard