@nimakro Relax and enjoy the weekend 🙂

As a follow up to the binding issue: TornadoFX' Properties.kt actually has a stringBinding Method which allows a quite concise syntax:

masterUserProperty.stringBinding { it?.name ?: "" })

Am still gonna use a ViewModel, just for completeness' sake 🙂 (Essentially the same as my No. 3)

@doubleu Yes, that's fine for cases where you don't need to write back into the property. ViewModels can be used for a complete two way binding, with commit and rollback.

I have updated the Data Controls chapter in the guide with information about the new

cache

function, and how it drastically improves

cellFormat

performance and reduces the memory overhead.

If you ever assign to

graphic

inside of

cellFormat

, you should use this pattern:

@User uploaded a file: Best way to assign nodes in a cell

Cache is simple. Whatever is created inside the cache block will only be created the first time this function is called for the parent node, in this case the cell.

You can optionally supply a specific key if you would ever need to cache multiple node graphs:

cache("someKey") { buildMyNodesHere() }

I can't think of a use case for that, but I didn't want to constrain the API.

I also described

assignIfNull

as a middle way:

#### Assign If Null If you have a reason for wanting to recreate the graphic property for a list cell, you can use the

assignIfNull

helper, which will assign a value to any given property if the property doesn't already contain a value. This will make sure that you avoid creating new nodes if

updateItem

is called on a cell that already has a graphic property assigned.

kotlin
cellFormat {
    graphicProperty().assignIfNull {
        label("Hello")
    }
}

@edvin @jchildress Thanks for your sympathy, I relaxed last night. Work will be fine, it's just that I screwed up a bit but I guess sometimes the youngster have to learn it the hard way 🙈 @edvin Is the ListCellFragment also using the cache or is it introducing a much bigger overhead?

@nimakro Good to hear.. I'm heading out to Comicpalooza here in Houston in a bit with one of my sons 🙂

I find that relaxing 🙂

@nimakro The hard way is the best way to learn, you tend to end up understanding everything better that way 😎 The ListCellFragment uses the same mechanism under the hood, but also instantiates a Fragment instance for each visible cell. The memory overhead will be negligible. If you have a lot going on inside

cellFormat

it could help with keeping things clean. You could also just create a function and call

cellFormat(myfn)

.

I updated this EE tool to handle metric conversions driven off a ChoiceBox. The ChoiceBox modifies the ListView items and recomputes to a totalResistance property. Also added Spek and some unit testing in https://github.com/bekwam/kcircuit

Next week I'm going to add some keyboard shortcuts and a recall history feature that will highlight the new command class

@kastork commented on @carlw’s file https://kotlinlang.slack.com/files/U25U0KPFT/F5DUJHE5V/kcircuit_demo_1.mp4: Nice example

@kastork thx. this app features the MVVM architecture i wrote about last week

@carlw blog post somewhere?

my best docs are in the FX project (plain JavaFX). none of my clients are using TornadoFX, but everything in the docs applies here too https://fxdocs.github.io/docs/index.html#_the_mvvm_pattern

@carlw Maybe the add button should have a textfield next to it, so you can add the correct value right away?

@edvin what i'm shooting for is a keyboard driven Tab+Return data entry where a Tab or Shift Tab introduces a nested structure

i have more things i want to do on the listview...maybe upgrade to treetableview

@User uploaded a file: Any experiences with serializable jvx entity classes?

@jchildress That looks like a lot of fun

enjoy

@kastork Use JsonModel 🙂

meh