Optimizing FXML imports deletes classes needed in fx:define

[gluon-bot]

Originally reported by: A. Walter (Bitbucket: awalterwork, GitHub: Unknown)

---

In SceneBuilder 8.3.0, the FXML imports are "optimized" whenever the file is saved: Only imports for the exact classes used in the node tree remain.

However, when you used fx:define to define some objects, SB does not keep the imports for their classes when it saves the file - it just deletes them! (It does not make a difference if you were using wildcards or not in your imports.)

This means that after editing the file with SB, you cannot load the FXML file in your application anymore - SB effectively breaks it.

Steps to reproduce:

• Open the example FXML (see attached files) in the example application (see attached files): it can be displayed.
• Open the example FXML in SceneBuilder.
• Change something (for example, the text of the button in the red area) and save.
• Look at the example FXML source. There are not imports for the classes referenced only in fx:define anymore (ArrayList, SplitMenuButton, MenuItem).
• Try to open the example FXML in the example application: The application cannot start because of LoadExceptions like "javafx.fxml.LoadException: ArrayList is not a valid type.".

Expected Behaviour:

• SceneBuilder should save the file in a usable state, that is, with imports for all classes referenced in the FXML file.

---

• Bitbucket: https://bitbucket.org/gluon-oss/scenebuilder/issue/120

[Oliver-Loeffler]

@abhinayagarwal @AlmasB What do you think here? We also have many cases related to broken FXML reading/writing. I've found a way to keep track about imports which cannot be resolved by Scene Builder. So basically this can be introduced as an isolated feature.

As this is a significant change to existing behavior, I'd propose following setup:

1. There will be a new boolean in Preferences Unresolved imports are preserved during FXML load/save.
2. If the option is active (true), Scene Builder will only notify the user about the imports which cannot be resolved.
3. If the option is inactive (false), Scene Builder will inform the user that unresolved imports exist and those will be removed. This might break the FXML (depending on how it was used previously).

If one then updates the library, the document requires to be re-loaded.

Technically this would a huge step as the current way how Scene Builder reads/writes FXML sometimes breaks production flows. What do you think?

The technical approach is, that the com.oracle.javafx.scenebuilder.kit.fxom.FXOMDocument keeps track of unresolved imports and the com.oracle.javafx.scenebuilder.kit.fxom.FXOMLoader repeats its attempts to load a file until there are no more ClassNotFoundException errors raised by FXMLLoader. The FXOMLoader will remove each failing import from FXML text and attempt a new load.

I've a working example ready, whats missing is the preferences. May be its also beneficial the to offer a menu item which provides a list of the unresolved imports (e.g. inside View menu, above controller skeleton preview or in the inspector, below the Code area).

[Oliver-Loeffler]

Preferences dialog is now working. There are no notifications yet. I'd prefer adding user notifications with separate PRs (if even wanted).