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

[Daniel Zwolenski]

>
> > 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.
>

The Controller is suppose to know about the View in the sense of a 'black
box'. It shouldn't know about its plumbing. So for example, the controlle r
should know that its view has a 'currentlySelectedOption' but it shouldn't
know whether the View is using a ComboBox or an animated scrolling
ipad-like list to let the user choose that option. This gives you the
decoupling so your view can change without your controller having to.
Currently FXML shows way too much plumbing to the controller to be
considered an MVC, MVP, or MVWhatever, pattern.


> 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 ;-)).
>

If they are ever hiring, let me know. That would be awesome :)


> 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.
>

I'm building a system that chemical processing plants, and mine site
workers (among others) will hopefully one day use to shut down machinery
that can kill you (acid pumps, huge rotary blades, electrical wiring, etc)
while they go out to fix it. My bad code could literally result in the
death of another human being.

I want patterns, good ones - I don't mind a little extra bloat if it means
my code is less bug-prone and more testable!