<@U0F3291QE> I was testing the nested fxml and wro...
# tornadofxc
carlw
02/14/2017, 2:32 AM@edvin I was testing the nested fxml and wrote a pair of test cases. Look for the PR. There are 3 fx:include scenarios to consider.
1. Controller per FXML. I use this all the time to treat my Java Controller as a code-behind. This means the fx:included files get their own Java class with -at-FXML annotations for fields and methods.
2. Top-level Controller (includes TornadoFX View). The topmost FXML gets a Controller or View and those top-level fields are mapped with fx:id. Controls in the fx:include are accessed by the scene graph. I recall being able to -at-FXML everything, even included fields, but I couldn't get this to work in a Java-only (no TornadoFX) test.
3. Outside Scene Graph. The fx:include is in a fx:define and is not part of the Scene Graph. A Controller class is needed because the define is disassociated from the parent FXML. This seems suited to standalone windows like dialogs. I've never used this in 4 years -- mainly because it might not be possible to do this solely in Scene Builder.