webstart has - AFAIK - the killer advantage that it knows how to upgrade the JRE itself.

but i have never tried it.

with the new URL handler support, the browser integration seems much better. although there are some minor bugs they're fixing in 8u152 around custom splash images

it also knows how to use pack200 to make the downloads much smaller

(pack200 is a bytecode compression system)

Yeah, and that you can just request different versions for the app and it will take care of it.

Creating an URL handler is pretty easy for the main stream platforms though, so if webstart doesn't come through we need to create our own thing that can also update the jre's it manages.

jeez, 8u152 is not out until october 😞

Hey @edvin I am using a

ListCellFragment

but when I access the

item

inside the

ListCellFragment

it is always null🙈

yeah

it's too bad web start isn't totally open source

@nimakro That's because you access it in

init

, while it will only later be assigned a value.

(afaik)

Yeah.. But we could fix the issues with webstart if we go for a reimplementation. We could also avoid the stigma that comes with it.

@nimakro You can do

itemProperty.onChange

to react to when it gets a value, but it's far better to use a viewmodel, bound to the itemProperty of the ListCellFragment, and bind your UI to that directly in init or while building the root node.

@nimakro I think this is in the guide, if not I will make sure to add it.

@edvin Ah oky will do that, mhm maybe but I couldn't find it in the

5. Data Controls

chapter...

@nimakro I will go over the guide tonight. Thanks!

@edvin No problem and thank you for all your work 😉

My pleasure 🙂 Working on the guide now.

Guys, I'm thinking about deprecating

cellCache

. It is wasteful with regards to both memory and CPU. When

cellFormat

isn't enough, I think

ListCellFragment

is the right solution. It uses only slightly more memory than a custom ListCell implementations and has many benefits.

We could introduce a way to create a

ListCellFragment

using builders instead, so the ceremony is reduced a little, although it is actually nice to get the ListCell UI code out of the builder hierarchy that defines the ListView.

The guide talks about

cellCache

where it really should have talked about

cellFormat

, and didn't mention the

ListCellFragment

. Sorry about that @mikehearn - I see now why the guide sent you on the wrong path. Updating now.

I must be missing something obvious. When a value in an instance of a data class, in this case a

JsonModel

, not a kotlin data class, changes, then should not that change propagate through the associated

ItemViewModel

which is backed by that data class and thence into the view (in this case, a Table)

@kastork I use the EventBus to notify the viewmodel that it can go get a change from the model. then the viewmodel is bound to the view and the view will automatically update

there's another pattern where the EventBus can carry around a value. I prefer the former solution since a ViewModel might need to cross reference another model when an update comes in

@carlw Thanks, that makes sense. But I thought the whole idea here was to have a reactive UI -- data changes => ui updates

the viewmodel reacts to an event and goes back to grab the data. in my case, that data has already been retrieved. the async part is this 1. issue an async request from the view model to the model 2. the model takes its time getting the data 3. the model posts an event to interested parties (1 or more viewmodels) 4. the viewmodel receives the event and fetches the saved / cached dat 5. the view is automatically updated b/c the viewmodel is bound

but you have to manually set up the interested parties