@User uploaded a file: Rx ViewModel Test

@User uploaded a file: bandicam 2016-09-09 02-05-05-331.mp4

It's a bit tricky I had to do

model.dirtyProperties.onChangedObservable().map { it.any { it == model.name } }

to determine if a specific property was dirty. Although it wasn't difficult since I obsess over Rx to JavaFX patterns, it might be considered boilerplate by others. I think this was discussed before between you and @Ruckus , but I can't think of a streamlined way to add a "Dirty Property" to a specific

Property

without inflicting even more overhead on the

ViewModel

. I guess that's when tools like Rx can come in handy.

@Ruckus: looks good the new builder

@thomasnield Very nice! I think we can even find a way to deal with the dirty property without adding weight to the ViewModel, I will give it a try tonight (if I have time, my pipe line is growing here :)

@Ruckus Very nice work on the builder, and thanks @ron for bringing this up. We needed to fix that 🙂

@thomasnield You can now get a

BooleanBinding

you can listen to for a specific model property like this:

model.dirtyStateFor(ClientModel::name)

. This should clean up your use case a bit - will you document in the guide then I'll do the wiki? 🙂

@thomasnield I will update the guide as well 🙂

Wiki and Guide updated!

The non-rx way of doing what you do above would be:

@User uploaded a file: Untitled

Maybe we should add an example like that to the guide?

@edvin wow nice. Thanks, those individual dirty properties are very valuable

@edvin: Did you get a chance to look at the weird expand usage I ran into?

@Ruckus Sorry, I must have missed that - what was it?

seems TornadoFX plugin is incompatible with latest EAP of IntelliJ

(well, EAP+Kotlin plugin 1.0.x EAP)

@mikehearn As in it fails, or it is not available because of version mismatch?

exception

@mikehearn OK, thanks 🙂 I will fix it tomorrow and let you know 🙂

@mikehearn I just installed the latest EAP, installed the plugin and created a new project based on the maven template. Clicked the Tornado in front of the app class and the app launched just fine. Is it a specific action that's not working for you or where does it fail?

I also tested "Create TornadoFX Property", "Create ViewModel", "Create New View" without issues.

Send me the stack trace and I'll figure it out though 🙂

@Ruckus About your comment on the latest PR: Did you mean that the PR is not necessary?

I'm not sure. I don't believe it is, but I'd have to mess around with a few test cases. Hopefully I'll get a chance to soon.

OK, great! I'm mostly of of commission until Monday, will catch up on everything then 🙂

@edvin I've looked more into the PR, and it depends on what we decide is necessary. It is necessary if we want to allow code like

SimpleObjectProperty<Date?>

. That code isn't necessary in the sense that

SimpleObjectProperty<Date?>

is technically no different from

SimpleObjectProperty<Date>

. Even the

var date by dateProperty

would be of type

Date?

in both cases, and the

dateProperty.value

is

Date!

in both cases.

It does add an extra reflection call to accept

Type?

, but I don't know what the impact will be. It's a change from

T::class.javaPrimitiveType ?: T::class

to

Class.forName(T::class.jvmName)

.

Since the actual code usage is technically the same, it all comes down to readability. Jonathan is correct that Kotlin developers would probably see a distinction between

Property<Date?>

and

Property<Date>

even if one doesn't exist.

The impact of this PR would be minimal as this would only come into effect when using the

bind

function you defined on classes that have a

textProperty

, but it could mean we would have to make sure we are supporting it in other places as well, both current and future.