Load view (only) when controller is injected

[hallvard]

If I understand this extension correctly, it loads an instance of all controller/fxml pairs (when the controller is annotated with @FxmlView that is) during startup. I find this confusing and would prefer having more control of when controller/fxml pairs are loaded. Why not allow injecting the controller (or creating it with Instance.get()) and autoloading the corresponding fxml view only then?

The behaviour I envision is a bit like the following:

class MyController {

  @Inject FXMLLoader fxmlLoader;

  @PostConstruct
  void loadView() {
    fxmlLoader.setController(this);
    fxmlLoader.setLocation(lookupFxmlResourceWithStandardRules(this.getClass()));
    fxml.load();
  }

  ...
}

Later you just @Inject MyController myController to create (or reuse depending on the controller's scope) the controller instance and auto-load the FXML.

The point is loading the view and having the usual FXML-injection done just after the controller is fully created. This way, the fxml loading process is hidden, while still giving you control of when it happens (you can annotate the MyController with any scope, @dependent, @ApplicationScoped or other). The controller can allow you to get nodes in the view, so they can be attached to the scene graph (stage, scene or lower down).

I only have a rough understanding of quarkus extensions, I imagine it would be possible to auto-augment @FxmlView-annotated classes with the above field and @PostConstruct method (or similar that gives that effect), to make this work? If it's possible, I think it may remove the need for FxmlRepository, thus simplifying the extension, but I may be wrong.

This seems related to #75 as it also is about giving more control of when loading is done.

[hallvard]

I've looked more into this... there are two approaches that are possible. Both rely on an injectable helper object, I've named it FxViewLoader, that contains the logic for loading the FXML for a specific controller (including logic for looking up the FXML resource).

The first variant is the one sketched above: The controller includes a @PostConstruct method that uses an injected FxViewLoader:

@Dependent
public class FxSampleController {
    
    @Inject
    FxViewLoader fxmlViewLoader;

    @PostConstruct
    void loadFxml() {
      fxmlViewLoader.loadFxml(this);
    }

   ...
}

An instance of FxSampleController can be now be injected, e.g. in a start method:

  @Inject
  FxSampleController fxSampleController;
  
  public void start(@Observes final FxPostStartupEvent startupEvent) {
    var stage = startupEvent.getPrimaryStage();
    var scene = new Scene(fxSampleController.getRootPane(), 1000, 800);
    stage.setScene(scene);
    stage.show();
  }

Note that with this technique the controller can control it's scope, e.g. it could be @ApplicationScoped, and there is actually no need to use the @FxView annotation, since there's no magic necessary. The downside is that FXML loading by means of FxViewLoader is explicit, it would be nice of the fxmlViewLoader field and the @PostConstruct method could be added auto-magically, e.g. by using the @FxView annotation.

The other approach is using a producer method in another bean:

@ApplicationScoped
public class FxSampleControllerProvider {

  @Inject
  FxViewLoader fxViewLoader;

  @Inject
  Provider<FxSampleController> fxSampleController;

  @Produces
  @WithFxml
  public FxSampleController createFxSampleController() {
    return fxViewLoader.loadFxml(fxSampleController);
  }
}

Note that we need a qualifier (here named @WithFxml) on the producer method, to avoid conflict with the unqualified controller. This qualifier is also needed at the injection point (which actually is nice, since it reminds us that more is happening). In this case the controller becomes simpler, since it doesn't need the fxmlViewLoader field and the @PostConstruct method This approach might seem more complicated, since we need an extra class, but this class can be used for all controllers in a project, with one method pr. controller. The main advantage is that this class can be auto-generated from annotations, hence, you only need to annotate the controller and inject it with the qualifier. This is very little extra work, while giving control of when controllers are created and FXML files are loaded.

An extra advantage is that the generator for this class can incorporate the FXML 'compiler' I've mentioned earlier, to avoid actually loading FXML using reflection.

I'll look more into the generator for the producer class, now, and provide an example repository to demonstrate it.