Thanks
for the grt post!

Being able to have a cell factory is crucial to virtualization, which is itself crucial for virtualization.

So instead, what you have to do is return a single Cell which is capable of rendering any of the items. If you have, say, 2 different types of cells you want to display, then each Cell has to have 2 different sub-scenegraphs and then choose which one to use as the “node” based on the current index. SO for example:

cellFactory: function() {
def cell:ListCell = ListCell {
node: bind if (cell.item instanceof Customer) { /* some node to represent it*/ }
else if (cell.item instanceof Order) { /* some node to represent the Order */ }
}
}

Or you can just have your custom cell have a variable for each type of sub-scene and lazily create them on demand, and then in the onUpdate callback do the switch there instead of using “bind” as the above code would create & throw away the subscenes pretty frequently.

My calculation here was that it was better to provide a very simple cell factory interface rather than force developers to manage a pool of cells manually, with the assumption that there would typically not be a very large number of different renderings in a single list. If you find you have a use case where you really do have a lot of different cell types in a single list, then you could go all the way if you wanted to by doing something like a ListCellComposite subclass of ListCell that would take a sequence of ListCells, or have a ListCellCreator subclass that would have cell-pool functions built into it and a shared HashMap or something of cells.

For example, suppose you had 100 different cell types to render. Under the basic API we provide, if the ListView needed 20 cells, it would end up creating 20 cells which would potentially have 100 different sub-scenes — and that 2000 different subscenes could be quite taxing on memory and such. Instead, suppose your implementation of the ListCell could refer to a pool of subscenes. When it needs one, it checks it out and assigns it to its node. When it is done with it, it puts it back. In this way you have 20 cells and only another 20 sub-scenes at first. Over time if every variation was used you could get up to all 2000 different subscenes, but it is unlikely, so you would probably save memory. Of course they could be housed in soft references so they are free’d if memory gets tight.

Anyway, something to stew on

Are there limits to the flexibility that the cell factories support? If I have a really heterogeneous sequence of data to be rendered in a single list how would I go about creating wildly different nodes based on the type of data?

Thanks,
Keith

Articles such as this re-affirm my faith in the JavaFX platform.

Go JavaFX …

Listview{
items:[
HBox{
content:[
Label{}
Button{}
]
}
]
}

For me, this implementation does a very good job of giving me the control I need to make a component useful while shielding me from a lot of the complexity that would normally have me over engineering things in plain old Java.

I think you guys are striking a nice balance of flexibility vs complexity. I can see JavaFX being a very productive platform.

Good job!
Ryan