FXML Patterns / best practices
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>
<Button id="..." onAction="..." text="..."/>
</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