Maybe that is good enough.

this sticks to the paradigma you have been doing all along

have a view or a Fragment and add the root to another

Absolutely.

But this is one of the first real components we make ourselves, so it's not implemented as extension functions. Therefore we can do more advanced stuff as well.

of course we can, but you have (knowlingly or unknowingly) introduced a design pattern

I know.. I think this is actually good enough, but I will certainly add an example using a Fragment. It's so easy to do and I want people to know that it's possible.

sorry, I can be a bit fundamentalist when it comes to patterns 🔏

That's important and valuable 🙂

I put a Fragment into a custom ListCell last night. The TODO app I mentioned yesterday has a separate FXML forming a row in a ListView.

class TodoItemListCell : ListCell<TodoItem>() { override fun updateItem(item: TodoItem?, empty: Boolean) { super.updateItem(item, empty) if( empty || item == null) { setText(null) setGraphic(null) } else { setText( null ) setGraphic( readCache(item).root ) } } companion object { // TODO: clean up deletions from cache after removal from UI var cellCache : MutableMap<Int, ItemFragment> = mutableMapOf() fun readCache(item : TodoItem) : ItemFragment { val id = item.id.get() if( !cellCache.containsKey(id) ) { val itemFragment = find(ItemFragment::class) // prototype itemFragment.load( item ) cellCache.put( id, itemFragment ) } return cellCache.get(id)!! } } }

@carlw That sounds reasonable, but you don't need to subclass ListCell to do this, just override

cellFormat

. I will also introduce a

cellCache

feature to ListView so you can simply return the ItemFragment and don't need to think about caching manually or even overriding ListCell. You can remove half the boilerplate right now by using

cellFormat

and the rest of it tomorrow when I have the

cellCache

done 🙂

@edvin The ListView is by fxid(). Will I have to create my own ListView object or use a builder?

@carlw No that doesn't matter how you construct it, but you don't need to specify the cellFactory in your FXML anymore. I just committed

ListView.cellCache

now. Haven't even tested it yet, will create some tests for it tonight though 🙂

@edvin Great. I was psyched to use "companion object" at the time, but I'm sure the novelty will wear off.

the updateItem is that not a real candidate for the viewModel?

@ron What do you mean?

nvm its a custom listCell, not a cellFormat

I should read everything before blurbing

@carlw Basically you should be able to throw all the code you have above and replace it with:

@User uploaded a file: Untitled

That's a bit easier to maintain, no? 🙂 hehe

definitely

For the Fragments, does the find() function support custom scopes? Something besides prototype and singleton?

No, but it is actually allowed to instantiate fragments manually. They will enter the life cycle in the right place no matter how they are instantiated, so you can just create them when needed. Hence you should be able to support other scopes as well. If you see the need for custom scopes I would like to investigate if this is something Fragment could support natively though. Let me know!

@carlw I added a test and fixed a bug in ListView.cellCache so do a another pull before you try it. If you use this feature and are ready to submit your app before the next release I'm sure we can relase 1.5.7 by then anyways 🙂

sure. i have a big refactor to do that will add in the ViewModel...fighting the Kotlin syntax a bit

@carlw what was the link to that app?

@ron https://github.com/bekwam/todomvcFX

My additions are under examples/tornadofx