FXML Patterns / best practices

[Cameron O'Rourke]

I would like to second what Werner wrote. In my programs, since the controller is created, I can't inject dependencies and instead wind up wrapping them with an adapter that I call a "module" (makes sense for my app at least). 

-Cameron



On Feb 27, 2012, at 5:46 AM, Werner Lehmann <lehmann at media-interactive.de> wrote:

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