SceneBuilder and fx:root #57
Comments
|
Original comment by Joeri Sykora (Bitbucket: tiainen, GitHub: tiainen): I'm not 100% sure if it is actually invalid to specify an fx:controller attribute on an fx:root construct. This just means that you will always use that controller instance for the root object? The documentation for the |
|
Original comment by Michael Paus (Bitbucket: mipastgt, GitHub: mipastgt): I do not understand what you want to say with your comment. I am using the fx:root construct in my project and therefore I have to set the controller on the loader but this will result in an exception if the FXML file also contains the fx:controller attribute. So in this scenario the FXML file MUST not contain an fx:controller attribute. These are the facts or did I miss something? Another question is how to solve this issue because it would actually be nice if you could at least specify the controller class for SB just to get the additional features which I mentioned above. |
|
Original comment by Joeri Sykora (Bitbucket: tiainen, GitHub: tiainen): What I want to say, is that it's perfectly valid for an FXML document with the fx:root construct to have an additional fx:controller attribute specified. The developer that loads the FXML document with the FXMLLoader should in that case NOT set the controller manually, as that would give the exception you mentioned previously. You can always call FXMLLoader.getController() after you load the document to get a reference to the controller. If you absolutely want to specify the controller yourself in code, then don't set the fx:controller attribute on the FXML document. |
|
Original comment by Michael Paus (Bitbucket: mipastgt, GitHub: mipastgt): Well, I think I got your point now although I still think that having both attributes set in an FXML file just does not make sense even if it is formally allowed. If you set the fx:root attribute you do that on purpose because your software, e.g. a custom component, is designed that way and there is nothing wrong with that. That's the reason why this attribute was introduced. Of course I can then just leave out the fx:controller attribute to get this set-up working. That's what I am doing right now. The only problem is that SB then cannot deal with this scenario very well and you are loosing some nice features. |
|
Original comment by Joeri Sykora (Bitbucket: tiainen, GitHub: tiainen): And now I understand your use case better as well. The thing is that SceneBuilder only knows about fxml files: it reads all the info from the fxml file and it writes all the info back into the fxml file. To be able to support your use case, SceneBuilder should either have the option to assign a certain class as a would-be controller for the fxml, or there should a be a project-like functionality in which you would be able to store such information separately from the fxml. The first option would need to be done every time you load the fxml, but is a rather easy option to integrate. The second option introduces a whole new idea of managing SceneBuilder projects and is much more work I'm afraid, but probably a better solution in the long term. I think an issue as described in #14 might be what you are ultimately looking for. |
Originally reported by: Michael Paus (Bitbucket: mipastgt, GitHub: mipastgt)
In SB you can specify a controller class for your FXML-files. This is necessary in order to get proposals when you fill in fields like the fx:id which is very usefull to avoid spelling errors and not having to look up the possible values manually. However, when you also check "Use fx:root construct" the controller definition is still written to the FXML-file which is wrong and results in an exception " javafx.fxml.LoadException: Controller value already specified." when you later try to load the file and specify a controller instance which is the whole puprose of the fx:root contruct.
One solution would be to not write the controller definition to the FXML-file if the fx:root construct is used. But, if possible, I'd like SB to remember the controller definition so that I do not have to specify it again each time when I open the FXML-file.
The best solution would be to fix the JavaFX-Loader so that it checks whether the provided controller instance is compatible with the specified controller type and only throw an exception if this is not the case.
The text was updated successfully, but these errors were encountered: