FXML Patterns / best practices

[Greg Brown]

>> As far as I'm concerned, this aspect of the design is not up for debate.
> 
> I think it is, why would it not be? The thing I like about Dan's proposal is that it sits quite naturally on the current design. The reason the current design was approved for 2.0 was that it appeared to me that we could improve on it beyond the current "code behind" concept.

Maybe I'm reading it wrong, but it seems like Daniel simply doesn't like the existing controller model and would like to replace it with something else, and I just don't think that makes sense. It works well and, in my opinion, has many valid use cases.

> I don't think MS is the gold standard in MVC design

I don't believe the "code behind" model is necessarily an attempt at MVC. It is just a way to bridge markup and code, same as we have done with FXML and the controller. From that perspective, I actually think that Microsoft did a very good job with the design. Note that Flex uses a similar (though not identical) model, and frameworks like PureMVC have been successfully built on top of that. I don't see why Daniel couldn't do something similar with his ideas. In fact, that's exactly what I tried to prototype using his original example.

> I don't understand why we want to limit our design pattern to just this one?

Am I just not expressing myself clearly? I don't think there is anything in the existing design of FXML or the controller architecture that prevents other patterns from being used or built on top of it.

> all he's really asking for, if I understand right, is for a way to (a) reference from FXML variables which have been loaded via the namespace by the loader, and (b) give those elements a "type" for the sake of tooling.

Isn't that the "param" model we talked about a few months back? If so, I think that's a separate discussion from this particular issue.