FXML Patterns / best practices

[Richard Bair]

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

Oh I would agree it is a valid model and there will be plenty of folks who are satisfied with it.

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

Ok, I think for many of us we think MVC / MVP, and are attempting to put the square peg (FXML + FXML "controller") into the round hole. I will have to spend some time looking at the code samples in more detail. 

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

Ok I will dig in and try it out more faithfully.

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

I think it is all really related. The param idea allows Dan or whomever to inject their own controller concept into the FXML file, without having to use the fx:controller concept at all. That idea really resonates with me. The core of the FXmL file is the serialization concept, and all that stuff was brilliant. I think we then tied it to the code-behind controller concept. I think having fx:controller tightly coupled with the FXML file clearly isn't what many senior devs are looking for (that is, I think everybody who has come to us not wanting to use fx:controller are all senior developers, not that there arent also senior guys who like the current design). The param idea decouples it. The other stuff we're looking at, like an FXML Controller base class, etc, improves the code-behind pattern which we have more or less canonized, and I think that is good (improving EdHat we've got is a good thing). However that shouldn't preclude adding param and decoupling FXML from FXML Controller and making Dan and company happy.

To be honest, there are so many different FXML controller threads right now I might be commenting on the wrong one, but doing my best :-)