You can add

println(fxmlLoader!!.namespace)

inside

init

to check what was found by the loader.

i just pushed up my changes w. a PR...the test is broken, so feel free to reject

get a little code review practice in

this is a typical pattern that i use: a composed view of several parts. each part (included using fx:include) has it's own controller. since i'm using MVVM, this controller is a code behind with nothing more than binding and delegating actions

OK. First comment: You don't need to include the path of the sub-loaded controllers, it's already dictated by the include, so just use

by fxml()

.

You mean the file path? i was copying Inside and Outside

Inside doesn't specify the fxml path, only Outside.

For this reason 🙂

If Inside was used standalone as well, it could benefit from this, but when it's included, it must be ignored.

I've never checked out a PR before. Trying 🙂

This is very valuable @carlw. It seems that actions aren't resolved correctly. My first thought is that it would look for the

search

function in the main controller, but adding it there failed as well. Never used action references like this, need to investigate.

Ouch, need to make dinner and get to Jiu Jitsu practice. Will check this ASAP! This Valentines business might reduce my coding time today though. Grr..

Ah, I think I know what it is. I use a "placeholder" controller while parsing the FXML, and this of course doesn't have the

search

function. Maybe my approach will not work after all then.

Very good that you shone some light on this Carl!

The reason for this issue is that I can't instantiate the sub-controllers until the complete FXML is parsed with my current approach. I don't see any easy way to fix that either.

I confirmed that this is infact the issue. I added

fun search() {}

to the

NestedController

(placeholder) class, and the test passed.

This could be fixed if

ControllerAccessor

wasn't final.

The reason I'm using controller placeholders is that the controllers (Views) might try to access the

root

element in their

init

block, but when I create the controller in the

controllerFactory

callback, the node isn't even constructed yet. (Because the XML parser is still processing the attributes of the fxml element that represents the root object at this time).

I'd have to disallow access to the elements in the

init

block of FXML loaded views and instead ask people to use

onDock

or implement

Initializable

.

This would be the cleanest approach, but could break existing code.

This requirement would only apply to nested views though, and they are not supported today, so maybe we can live with this.

There really are no good reasons for needing to modify the node hierarchy in

init

anways.

@edvin With the new include() TypeSafeBuilder, maybe a TornadoFXMLLoader is needed? I'm not anxious to parse XML, but that might give us flexibility to leave off the fx:controller attribute

@carlw Sorry I missed your question earlier, but Edvin is right. The JVM erases the generic type, so there's no way to check the type of list, only that it is a list. Some JVM languages have gotten around this by adding additional metadata in the bytecode, but Kotlin likely can't do it as it would probably break Java interop (Java code may not have the metadata, especially when working with 1.6 level bytecode).

@Ruckus thx

@carlw No, the

incuilde

builder doesn't seem to need anything special. I've thought about this some more, and since we don't break any existing functionality, I think we can impose certain restrictions on loading sub-controllers.

Kotlin could actually solve the type stuff in a Java compatible way by adding another class instead of modifying the byte code inline. It's certainly possible, but I don't know how important it is to "fix" this.

@edvin I think restrictions are fine. The requirement for fx:include will let the developer use Scene Builder and i don't think it's important to match javafx controller-by-controller

I'll try to rewrite it and we can re-run your tests and perhaps test some more use cases. Very good that you caught this!

I was mistaken. I can't rewrite it, because the

by fxml()

delegate will try to retrieve the root node, which isn't even available at this time. Chicken/Egg/Catch22 on steriods..