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

[Richard Bair]

>>> 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).
> 
> To me, this just seems a lot harder to understand and work with than simply mapping a named object in your markup to a field in your controller. From a pure MVC perspective, a controller is *supposed* to know about the view. Controllers are the glue that bind the view and the model together. So I'm not sure what you might achieve by adding this layer of indirection. But maybe I am missing something.

I think Martin Fowler does as good a job as anybody at the pro's and con's of these different patterns: http://martinfowler.com/eaaDev/PassiveScreen.html (scroll to the bottom for the "When to use it" for the quick story). A lot of these different design patterns come down to judgement and your team -- you might use one pattern if it was just you, another if it was you and some people you trusted, another if it was for a large team of random developers, another when you are writing a normal UI and another when you are writing software for the National Ignition Facility (Nuclear Fusion -- and believe it or not I had a tour and saw Swing apps running in there ;-)).

That's why I'm interested in supporting the various design patterns if we can do so without doing severe damage to FXML. I would absolutely want to use this pattern if I were doing UI for something where lives were on the line, because the level of testing and the clarity of the code is so there (but then I might do the entire UI in java with full static checking). I think it depends on who you're working with and what you're building and also just your own personal taste regarding the amount of code vs. the quality of the testing etc.

Richard