FXML Patterns / best practices

[Greg Brown]

> If you had to implement this sort of functionality (i.e. retrieve some data from a remote service, show it, allow it to be edited, using FXML etc) in your own application is this what you would use.

I'd personally skip the presenter and implement my view handling code in the FXML controller. We're not talking about a lot of heavy lifting here - in many cases, a controller just needs to send a request to the server and then populate/update the UI with the response, which can easily be done declaratively by bi-directional data binding once it is enabled. With the proposed enhancements to simplify access to nested controllers (http://javafx-jira.kenai.com/browse/RT-19755) and the addition of a message bus API (http://javafx-jira.kenai.com/browse/RT-17658), it will be much easier for controllers to communicate with each other, so I don't personally see much value in the additional indirection added by the presenter.

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

As far as I'm concerned, this aspect of the design is not up for debate. 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.

Greg