There was no way to keep the type parameter from Task, so I added a

value(someValue)

function that will call the underlying

updateValue()

function.

does anybody know the story behind

com.sun.javafx.binding.SelectBinding

and similar?

can i use them?

@groostav You get use it to bind against a property "deep" in an object graph. It's funny you should mention it now, because in the latest blog post I did I showed a way to avoid using the SelectBinding in favor of a ViewModel. It all depends on the use case of course. Do you have a specific need for it now?

It should be safe to use even if it's in

com.sun.javafx

. It's still part of the JDK 🙂

@thomasnield In the Components chapter we have this sentence: "See Section X to learn how to easily offload work to a worker thread using the

runAsync

construct". I want to describe this now, just wanted to check if you had a specific place for it in mind?

I quickly looked at the code for

SelectBinding

. If this is a thing people need and use I think we can leverage some TornadoFX/Kotlin features to make it much nicer.

care to link me to said blog post?

im happy to read it

and yeah one of the more common conventions we have is to bind a parent's

children

to a projection on a list of controllers

eg

class RootController {
  var subComponents: List<SubController>

  @FXML lateinit var vbox: VBox

  override fun initialize(){
    bindContent(vbox.children, subComponents.map { it.view });
  }
}

class SubController  {
  val view: Node get() = ...
}

the delegate passed in to

map

is a good fit for what should be passed into the

SelectBinding

.

unfortunately We dont have

Linq To Kotlin

yet...

@edvin I'm not 100% sureiof the

com.sun.*

packages will affected by changes in Java 9. https://blogs.oracle.com/java/get-ready-jdk9 and http://openjdk.java.net/jeps/260 I think they will maybe be renamed/moved?

@edvin I was planning on putting that in the appendix but put wherever you see fit

@groostav It's this one: https://edvin.town/leveraging-tornadofx-to-the-fullest/

@thomasnield OK, thanks, will do it today 🙂

@jchildress Yeah, I think some things might be moved to a new package, but I think some small refactorings will be needed for JDK9 anyways, so we can live with this, can't we? 🙂

@groostav Interesting approach, binding the children. This gives me some ideas 🙂

I made a small blog post about yesterdays hacking session 🙂 https://edvin.town/live-hacking-with-tornadofx/

How much magic goes into the binding? e.g, if I do

val x = bind { component.observable(IComponent::getX, IComponent::setX) }

and `component`changes, will the binding get updated to the new instance? I guess the answer is 'no', right?

The answer is

yes

. There is magic 🙂

Well, as long as

component

changes when the binding changes, that is.

I don't know where

component

is coming from in the above example, but the binding is reevaluated when the

item

is changed, or you call

rebind

manually .

So if I have this:

class Component : IComponent
var component = Component()
val x = bind { component.observable(IComponent::getX, IComponent::setX) }

and then do

component = Component()

the binding would be reevaluated?

I just changed

vbox

and

hbox

builders so the take a

Number

instead of

Double

. Now you can write

vbox(10)

instead of

vbox(10.0)

.

@permalmberg Then nothing will happen when you just change component, so you could either override

set

in your component var to rebind when it happens, or make the view model an

ItemViewModel<Component>

. Then you don't need to add the component variable, and

item

will represent the component.

@edvin override

set

? Is that a kotlin feature? in my case component is a POJO

@permalmberg Yes, it's a Kotlin feature. I thought from your example that

var component = Component()

was defined in the view model, that's why I suggested it. But I think using an ItemViewModel<Component> is much cleaner, if that's an alternative.