FXML Patterns / best practices

[Greg Brown]

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

OK. I think the param concept warrants some further discussion, though I'd personally like to see a more detail on how it would work and why it is necessary before we move forward with it. The code-behind model is pretty well established - Microsoft pioneered it with XAML, and we adapted it to work with FXML. It has taken a couple of iterations, but with the changes we've made for 2.1 and proposed for 2.2, I think it's pretty solid. 

The param concept is still really vague to me. I'd like to understand exactly what problems it solves that aren't or can't be addressed by the current design, either directly or by building on top of it, like PureMVC. If someone could put together 3-4 paragraphs that explain it, that would be very helpful.

Greg