FXML Patterns / best practices

[Richard Bair]

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:
> 
> <?xml version="1.0" encoding="UTF-8"?>
> 
> <?import javafx.scene.*?>
> <?import javafx.scene.control.*?>
> <?import javafx.scene.layout.*?>
> <?import examples.fxml.presenter.*?>
> 
> <VBox
>    xmlns:fx="http://javafx.com/fxml">
>    <TextField text="#{*model.firstName*}"/>
>    <TextField text="#{*model.lastName*}"/>
>    <ChoiceBox> <!-- selectedItem="#{*model.gender*}" -->
>        <Gender fx:value="male"/>
>        <Gender fx:value="female"/>
>    </ChoiceBox>
> 
>    <Button text="Delete" onAction="#*presenter.handleDeleteButtonAction*"/>
>    <Button text="Save" onAction="#*presenter.**handleSaveButtonAction*"/>
> </VBox>
> 
> 
> 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 <param> tags at the top of the
> file somewhere to allow these types to be defined, e.g.
> 
> <param name="presenter" type="examples.fxml.presenter.PersonPresenter"/>
> <param name="model" type="examples.fxml.presenter.PersonModel"/>
> 
> 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.