FXML Patterns / best practices

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


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. Tedious stuff moved to FXML

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

   <Button id="..." onAction="..." text="..."/>

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


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