FXML Patterns / best practices

[Richard Bair]

>> Looking at this proposed implementation, we've now got FXML in there for building up our Scene Graph, which is fantastic but the need for this extra FXMLController is a new cost. ...
>> My question: is this cost one we have to pay, or is there a way to avoid it (by potentially tweaking FXML)? 
> 
> Let's be honest. This is hardly a major burden, and is literally no different than how it works in .NET. In .NET, a XAML file and a C# file are combined into a single class. You must have both in order to create the class, since the XAML itself does not define any behavior - only structure. The behavior is provided by the C# file, which implements the "code behind" the markup. In JavaFX, the structure is defined by FXML and the behavior by the controller class, but the concept is identical. Unlike XAML, FXML isn't compiled, but it is functionally the same. And even if it was compiled, you'd still need the controller, because FXML itself isn't sufficient to define a class - you need both the structure and the logic.

I know you have long maintained this design philosophy, but in my mind this has never been compelling. Personally I do not like the code behind concept overly much.

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

I don't think MS is the gold standard in MVC design, I don't understand why we want to limit our design pattern to just this one?

> It addresses a lot of use cases and, in my opinion, does so very well. And as I have repeatedly mentioned (and demonstrated), you can easily layer whatever design pattern you like on top of it. Or you can choose not to use it at all. It's entirely up to you.

With various contortions, yes. But 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. I don't see what is objectionable? It seems a very nice addition. I think this also solves the fx:root issue on the forums without introducing a new concept as well?


> 
> Greg
>