FXML Patterns / best practices (original) (raw)

Richard Bair richard.bair at oracle.com
Fri Feb 24 13:57:58 PST 2012

Greg,

You asked what I agreed with. I've included it below. This is the "param" idea again, which I think makes perfect sense and really opens FXML up to other usage scenarios beyond code-behind.

In the context of this pattern, would it not be better if we could just pass those properties (i.e. the model and presenter) straight into the FXML file and dodge the need for this FXMLController. i.e. our FXML would look something like:

<VBox_ _xmlns:fx="http://javafx.com/fxml">

So the above FXML, instead of assuming there is a PersonViewController is just assuming there is a variable in its name space called 'presenter' and another called 'model'. The thing loading this FXML is responsible for providing these. For me this seems a lot better as we've avoided the PersonViewController, resulting in one less Java class and implementing our View 100% in FXML. Are there reasons anyone can see for not supporting this in FXML? (I'm also aware we can achieve something sort of like the above using JScript and some mucking around, but that's messy and not really 'supporting' it, in my opinion). One drawback for me is that we've lost the 'type' that was defined by the fx:controller declaration before, which means IDE/tools can't help us if we misspell properties or methods, or they don't exist, etc. If this was important (which I think it is) we could add tags at the top of the file somewhere to allow these types to be defined, e.g. This is very similar in concept to defining fx:controller="examples.fxml.presenter.PersonPresenter" only more flexible as anything could be used to handle callbacks, whereas in the fx:controller option, it has to be the "controller". As a side benefit, we also resolve our whole naming clash issue, as I can call it a controller or a presenter or a handler or whatever I like. This approach also fully allows for the current FXML design pattern, i.e. a non-MVP one where a single view-controller is used as a 'backing bean' and there is no actual model. You would just declare the 'controller' as a param instead of using the fx:controller attribute. So no one is hurt by this change, and the MVP pattern benefits.

More information about the openjfx-dev mailing list