Unless I can do something tricky in the

fxml

delegate in these cases then...

Nope, not possible.

@edvin how hard do you think it would be to walk through a .fxml and call Type Safe builders during the traversal?

@carlw Why would we do that? And what would we do for stuff that has no builder counterpart?

Did you mean as a way to implement FXMLLoader?

yes, to get nested fx:include views with Views or Fragments using fxid

i think the fx:controller is a problem

No, this whole mess is actually because I can't inspect the whole XML up front.

But we could write this as a generic FXMLLoader, just with the right hooks.

parsing listeners!

Yes. But the callbacks would probably fire when the complete object is available, not while the attributes of the open tag is parsed. That's why I have this issue, because that's the point where the controller factory is invoked. Before I can construct the root node needed by the fxml delegate.

An alternative here is of course to take a hard look at how fxml is supported in TornadoFX and change that instead. I haven't even looked at that, so that's worth a shot.

i think you'll end up with 2 options. 1) follow along with javafx and create tornadofx objects where javafx creates a controller (fx:controller) or 2) roll all the fxml together in a top-level view. The second option would need some type of namespace protection for fields that might share the names of other included fx:ids.

things seem to work well for one level, so maybe the second option is the next logical step

IMHO, this is to provide WYSIWYG support and not to leverage what's done in JavaFX

Is it allowed to reuse

fx:id

inside an include?

I think I've found a possible way out of this even with the current structure. Testing now.

great...not sure about the fx:id being unique through the scene graph. i'm also thinking about the methods that might get referenced like onAction="#go" where you'd like the .fxml -referenced go() to be in the fx:controller

i don't have any docs on this, but I think the fx:id is unique through the XML document

That's my understanding as well.

The

onAction="#go"

issue will go away if I can make this work.

I made the change, and was hopeful and happy.. ran the tests and all failed.. hehe..

Maybe we should get something going in testapps? a bunch of buttons that call FXMLLoader on different .fxml files?

Hang on, need to sort this.

The IDEA debugger is bugging.. I can't set breakpoints, so this takes a lot longer than I'd hoped.

@edvin what is it with you and the maven-gpg-plugin?

@ron What?

you always set it in the install phase

I remember that was my first PR for tornadofx putting it on the deploy phase

and fxlauncher has the same