Sure. titleProperty is not private, so I'm not sure why it's not being recognized

@abhinay uploaded a file: Untitled

Check this snippet and let me know if it works/makes sense.

did it work for you?

it didn't work for me

I'm still getting and unresolved reference

A compile time error?

It turns out your way is generally correct - no issue with numbers but there's an issue for string properties. Compile time is returning

Error:(148, 90) Kotlin: Unresolved reference: titleProperty

Well hold up, the other strings did work, just not this one

it must be me....

I am on TornadoFX v

1.7.11

and Kotlin v

1.2.0

, if that helps 🙂

hmmmm I know I'm using TornadoFX

1.7.12

Anyway, it must be some kind of typo

it recognizes other string fields but not this one. Maybe it's one of those things where I just need to see it in the morning

Haha, may be.

Edvin might want to update his json example on kitchensink, unless there was a really good reason to use itemviewmodels along with jsonmodels

The reason it wasn't working with your earlier snippert is because you were doing exactly what Edvin has asked to take care of in the docs i.e. referring to

titleProperty()

method instead of

titleProperty

field.

ahhh that makes more sense

Gradients are back! A Look Ahead: Web Design Predictions for 2018 https://webdesign.tutsplus.com/articles/web-design-predictions-for-2018--cms-30454

@amanda.hinchman-dominguez I think I haven't gotten this point through to you yet: JsonModel has absolutely nothing to do with JavaFX properties and bindings 🙂

The ui element builders also have built in binding, so instead of doing

textfield().bind(tileBuilder.titleProperty)

you can do

textfield(tileBuilder.titleProperty)

.

@amanda.hinchman-dominguez JsonModel and ItemViewModel differ in that JsonModel represents Record State (what's saved somewhere) and ItemViewModel represents Screen State (what you see on the screen). These could be made one-in-the-same in that an update to a TextField could automatically update a database. However, it's more practical to make commit points where saving is coordinated. This way, you can address performance concerns (RESTful calls for each key press would make the system unusable) and can prevent works-in-progress from being written out (ex, save "Ca" instead of "Carl").

And in every situation where you need rollback, commit or validation you should always wrap the tileBuilder in a TileModel

Thanks for the great explanation @carlw 🙂

It's from a Martin Fowler post I read.

@carlw this is an excellent explanation. thanks so much

Is there any problem with using TornadoFX and JFoenix?

None.

For example if you are using plain JFoenix, just add

this += JFXButton().apply {}

inside your view root.