@User uploaded a file: Untitled and commented: Blue coat proxy does a man in the middle attack

@edvin already had to solve it for git some time ago: https://ronsmits.org/2016/11/gitsslverify/

@ron Please do 🙂

@carlw Thanks a lot, I will look over the test cases to see if you covered what I was hoping for! Looks good 🙂

Good I'll add it tonight

@edvin I haven't used this, but there was an enhancement to subcontrollers added to javafx 2.2 that lets you inject a root and a subcontroller into another controller. The mechanism that does this is an fx:define / fx:include pair which does not add the fx:include into the scene graph. http://docs.oracle.com/javafx/2/fxml_get_started/whats_new2.htm

@User uploaded a file: subcontroller.zip and commented: Some source demonstrating an fx:include technique for creating dialogs; the oracle docs don't really show the use case

@edvin the zip i attached is an example based on the oracle docs that show how a controller might use the fx:included field and controller

@edvin I recall being able to combining -at-FXML annotations in a toplevel controller from included FXML elements but can't seem to get this to work. I don't have the time to investigate this hunch right now. I think this modality might be good for TornadoFX since the users won't be specifying a Controller class with each FXML. That is, the fxid() constructor would flatten all the fx:included files' ids. The test case I added has an impractical Scene graph navigation to validate that the Nodes were created correctly, but no one will want to program like that to get at included contents.

@edvin Maybe there's a post-FXMLLoader step that TornadoFX can do to chase down all the fx:ids via a Scene graph traversal and wire them up? I'm not sure yet if there is a problem with the current FXMLLoader using fx:id without specifying Controllers

@carlw Sorry for the late reply, swamped at work today. I'll describe how the nested controller support works and look all this over tonight 🙂

@edvin np. check in w. me later

@edvin for your blog thingy (the Boss?) what did you use for the markdown rendering? is there a repo of this somewhere?

@ron It's MarkdownFX 🙂

@carlw I'd like to include some controllers in some of the subviews, and see that we can get to the subview controllers from the main controller by

val subController: SubControllerType by fxid()

. I could add it myself, but I want to see if you think the way I assume people do, or if you'll run into issues because of things I didn't anticipate. Doable? 🙂

thats a complete editor 🙂 I was thinking of only rendering a "What's new" thingy

@ron You can disable editing 🙂 There is a library in there that does the markdown to node hierarchy conversion though, but it doesn't convert to JavaFX nodes for you.

It would be some work to use that underlying library and turn it into textflow elements for example.

there is a MarkdownPreviewPane

@edvin I think the biggest obstacle is needing something in the fx:controller tag which is needed for FXMLLoader when there are fx:ids...I'm going to test this a little more tonight

@carlw Great! It's these kinds of things we need to look out for. I hope I've nailed the implementation, but I might have made some wrong assumptions. Very eager to see how that plays out. If I write the tests myself, I know they will pass, because I'd write them in a "implementation biased" manner, so they wouldn't be worth much.

One thing to look out for. You need an

fx:id

on the include. In the root node of the included file, you need

fx:controller

pointing to the class of a UIComponent. However, if you add an

fx:id

to the root element, it will probably be overriden by the

fx:id

on the include. This is default JavaFX behavior though. Also, the controller would be called

fx:id

-from-the-include +

Controller

.

What are the classes involved in the solution? Just one View supporting the multiple .fxmls?

No, each sub view can have their own controller, and you can access the included controllers in the surrounding controller using

by fxid()

.

you have a Kotlin class specified in the fx:controller attribute?

Yes 🙂

It also supports non-kotlin or even non-tornadofx classes for the controllers, but they would not be injectable.

A good test would be to have a separate controller for an included form.

that's what i do outside of tornadofx w. plain javafx

Yeah, and finally we can support this in a clean manner. Actually very grateful for this github issue.