FXML Patterns / best practices (original) (raw)

Werner Lehmann lehmann at media-interactive.de
Mon Feb 27 05:46:13 PST 2012


Richard,

FWIW, I did not specifically like or dislike the params idea. My comment was purely about the way in which FXML content gets wired to backing code.

Currently the loader automatically creates the root element instance, and optionally the controller instance. But it is not really that optional because otherwise we could only use Node.lookup to add event handlers etc.

Instead of this I'd like to have the option to provide instances for the root element and the controller, allowing me to use one existing instance for both. In this way scene graph building could be delegated to FXML in a seamless way:

Consider this pseudo code:

A. Handwired, no FXML

class MyControl { private Button b; public MyControl { b = new Button(); b.setId(...); b.setText(...); b.setOnAction(...); ... } }

B. Tedious stuff moved to FXML

class MyControl { @FXML private Button b; public MyControl { Util.load(this, getResource("MyControl.fxml")); } }

fx:root

I suppose that this would work for MVC or MVP as well because we are simply replacing some init code without changing the structure. For instance, if somebody wanted to have a separate controller/view/etc class they could instantiate it and use similar code to the above in that class - with the added bonus that they already have a reference to that instance.

As to the params, personally I don't need them urgently... They remind me a lot of property expressions, e.g. as provided by OGNL. At any rate, I'd be careful with wildcards like text="#{model.firstName}" or onAction="#*presenter.*handleSaveButtonAction". Being unspecific like that is an opportunity for error, plus it would force to iterate the whole property tree via reflection.

Just saying...

Werner

On 24.02.2012 23:05, Greg Brown wrote:

My understanding from reading this was that Werner just agreed with Dan -- "Currently I don't see that value in the FXML controller in the general case" Take a look at the thread in the discussion forum, which I think provides more context for his comments.



More information about the openjfx-dev mailing list