...a nice big chunk of logic with some is statements...

Possibly. If the return types are correct. If you bind towards a property of a nullable type, the facade property should also have a property with a nullable type.

It seems like for @bkenn's case that the problem was limited to the null assignment. If I set his nullable to an empty object, it picked up the right bind(). Maybe a Kotlin thing?

@carlw If you don't pass in a nullable value, you'll end up with the platform type, so that would be interpreted as not nullable.

I ran this main. I was surprised by the difference between y and z. It seems like kotlin is considering as much information as possible at compile time. So, the null has no type?

@carlw You're checking specific instances to check their type. Since

y

is null, it can't be an instance of

StringProperty

.

z

however, is an actual instance of

StringProperty

. The fact that it is nullable is secondary, since it's not when you check the instance.

is

is the same as

instanceof

in Java, basically.

y

is also a

Property<String>?

, but due to type erasure, you can't investigate the type parameter at run time.

right. that's my "java oriented" suggestion. bind() today can't distinguish between StringProperty? and String? so you need to interrogate the object later and see if you need the toProperty().

StringProperty?=null won't match the bind() method with the Property<N> parameter, right? It looks like bindField is the fallback for anything nullable (389)

We still need the type definition to match, so not sure if this will work. Can't try right now, might not have time before I leave on Friday 😞

I updated the logo on GitHub btw 🙂

@edvin i think the workaround i proposed is ok. if @bkenn doesn't have a token, he can use an empty jwtString. so, in the model definition he can use =Token() instead of =null if he want an unwrapped javafx property

@carlw That is what I was thinking as well. I've implemented that work around for the time being.

i think we can do something in the body of the bind() method that's being called with the ? argument to avoid blindly returning toProperty() if not needed. IMHO it's better app design to pass around the empty container objects. That way, you can add functions like "isExpired()" without needing to check for null.

you can add an EMPTY_TOKEN constant too

Hello

I begin with TornadoFX and I want to say it's super!!!!

I have a small problem, I use a flowpane in my view . In my controller I do : mainView.flowpane().children.clear()

but no views are removed. I forget something?

@julienquievreux hi. from that example, it looks like you are creating a new flowpane() and then immediately clearing it of children (which it doesn't have). can you post a little more code? i think you'll want to keep a reference to the flowpane() you use in the builder as the target of your clear children operation

ohhhh ... I'm stupid ^^, yes it's a new FlowPane. So clear method works, but not on the node I look.

thank a lot for the help

🙂

here's a little code for reference

@carlw uploaded a file: Use of singleAssign

Thank you, I was missing the "by singleAssign()" part too....

@carlw Good catch 🎉

@edvin as a matter of style, do you like singleAssign or do you go over the scene graph and try to lookup parent containers from the event handlers?