No exception when fx:controller points to wrong codebehind class

[manuel-mauky]

See this example:

public class MyView implements FxmlView<MyViewModel> {
    ...
}

public class MySecondView implements FxmlView<MySecondViewModel> {
    ...
}

// MyView.fxml
<?xml version="1.0" encoding="UTF-8"?>

<?import javafx.scene.layout.VBox?>
<VBox xmlns:fx="http://javafx.com/fxml"  
    fx:controller="com.example.MySecondView">
</VBox>

This fxml file is named "MyView.fxml" but the fx:controller attribute is pointing to MySecondView.

If you load this with:

ViewTuple<MyView,MyViewModel> viewTuple = FluentViewLoader.fxmlView(MyView.class).load();

the MySecondView codeBehind and MySecondViewModel viewModel are loaded which is definitely the wrong behavior.

If you write this:

ViewTuple<MyView,MyViewModel> viewTuple = FluentViewLoader.fxmlView(MyView.class).load();

MyView codeBehind = viewTuple.getView();
MyViewModel viewModel = viewTuple.getViewModel();

a ClassCastException is thrown but if you only use the root view from the ViewTuple like this:

ViewTuple<MyView,MyViewModel> viewTuple = FluentViewLoader.fxmlView(MyView.class).load();

stage.setScene(new Scene(viewTuple.getView())); 

no exception is thrown. This error isn't simple to detect and can be easily be overseen by the developer.

The framework should detect this situation and throw an Exception in the moment the view is loaded.

[manuel-mauky]

Fixing this will be harder then expected. At the moment I'm working on a refactoring of the FxmlViewLoader class so that the loading process is easier to understand.
We will only be able to verify that the root view has the correct controller type defined in the FXML file.

For all other sub-views we can't guarantee this because we only know that the FXMLLoader is requesting a controller instance of a given type. We don't know at this point what the filename of the fxml file is. It's similar to the many other problems we have due to the limitations of the FXMLLoader.

However, like with the scope encapsulation and some other checks, we can include this in the upcoming dev tools (see #425).