3. Add an item "1".

The console also prints out a debugging line.

I'm wondering what you think might be triggering this onChange.

I see it and I think it's as expected. The reason is that the a item is also assigned a new cell, so the model adjusts to the new item.

So actually, if you want to make sure that you only refresh when there is an actual click you can listen to the completed.selectedProperty() instead.

If we used the editing functionality in ListView instead of the fake editing we could just listen to change events on the list, and we wouldn't need to call the label refresh manually.

Sorry - even listening to the completed.selectedProperty() would have the same result, since it is bidirectionally bound to the model.completed property 🙂

But everything is still good 🙂

I'm a little surprised to see so many completeds firing when I add an item. It looks a little stranger if you add 3 items (say "A,B,C"), check them all, then add a new item. You'll see 3 completeds fire. You'll see 6 onChanges if you take out the nv logic in the snippet above. It seems like you shouldn't get anything to fire -- say you're keeping a dirty flag around -- if nothing's changed.

You have to keep in mind that the fragments will be reused to represent different TodoItems all the time, so this is natural. However, it might indicate that this approach just isn't good for this sort of thing.

(If this is a problem in any way)

This is what you will get in one way or another if you bind/unbind in a cell implementation.

@edvin agreed! Transitions and

replaceWith()

need a bit more showcasing in the guide.

@thomasnield Nice!

@carlw It seems that the ListView editing support is not possible to use with FilteredList. I thought about supporting it in SortedFilteredList, but it's just too problematic.

@edvin i was looking over the other two examples. it seems like they're going the cache route where a model key points to a fragment I know this is can be an explosion in RAM for a 1000000 item agenda, but it keeps the binding straight But if binding isn't important, another design might just attach functions to all the controls and let a getUserData() provide an integer key that operates on the model and updates the controls

@edvin the handler behavior also shows up with the text, though we're not really paying attention to it consider this code

@User uploaded a file: Untitled and commented: handlers attached as placeholders for save operations

if you tell the framework user that these can set a dirty flag or a RESTful operation, then simply selecting the "Completed" filter will call the text.onChange for each of the todo items (I added 4 items and pressed the completed filter. This produced 4 "text changed" lines.

Yeah, I know. Although this works as intented, it might not be a good solution to this issue.

This example app is also heavily over engineered, with too many layers of abstraction for my taste.

For example, the

TodoItemModel

seems unnecessary.

Also that everything is a property just adds to the confusion 🙂

Hm... I managed to leverage the built in editing support of ListView by making the SortedFilteredList support editing 🙂

I wonder if I can avoid those pesky calls to

mainView.updateItemsLeftLabel()

🙂

If you look at my cellfragment branch in my fork...I pushed maintaining the active record count into the model. This opens it up for binding and works great with the add() and remove() operations. The problem I have with it now is the aforementioned completed() method which I can't count on to track with the actual completed operations. https://github.com/bekwam/todomvcFX/blob/cellfragment/examples/tornadofx/src/main/kotlin/todomvcfx/tornadofx/model/TodoItemModel.kt#L6

updateItemsLeftLabel() -- wherever it might live -- works because it can be called extra times without a problem but i think for capturing the best of the framework, you want a cleaner MVC implementation

IMO i think that it's ok to have the framework's listview() accept something like a RAM-heavy fragment cache. make the user write the mutableMap of the model object and its relevant item. This keeps the framework pure and maybe there is a better cache (fixedpool, etc) that can be plugged in at the user's discretion

In that case we can just use the cellCache function for this. It will use one fragment per item. No big deal for a Todo App 🙂

And much less code.