I've been using TornadoFX with it from day one, so not all parts of the app is using the latest syntax/best practices. It needs to be updated if it is to have any informational value. And I will definitely do that, but I think a more controlled sample will be more valuable.

If you look at the arrows, I can navigate between views like you do with the browser history. Really handy 🙂

It's a pity that you mixed the components DSL with a strong MVC. It complicates the picture a lot.

You did it for the sake of integration, probably, but still

but tornado is too good )) Now I have to fvguare out a way to use it with java

I'm not sure I understand what you mean @voddan?

I mean that I still struggle to understand the initialisation order. This is because Tornado tries to accept

KClass

and init the instances implicitly. For the same reason I can't pass arguments to the constructor of the View

@voddan So you should put your data in a controller so you don't need to pass it to the view, or you can have the view listen for events (with data). I will show you in this customer example 🙂

Then the

Controller

must be in Java

ohh

No, it must not. It can contain Java classes though, like the model or whatever kind of data you need access to.

I mean, I must init

MemoryModel

from a java code

since this is the part I don't work alone

@voddan But you can call that init method from the Kotlin controller right?

@edvin hi. what i mean by too many fragments is that many of them are pointing to the same model item. i tried your earlier unbind code, but the case "ov==null" never seems to arrive. here is a console showing the result of adding items a, b, and c

@User uploaded a file: Untitled and commented: A enter B enter C enter

@carlw Show me the unbind operation you're doing?

@User uploaded a file: Untitled and commented: From init() of TodoItemFragment

@edvin maybe a problem with the get and put on the mutableMap?

@edvin i also put a println() in the ov!=null block and never saw it called

@carlw Are you saying that ov is never not null? I tried that and it worked perfectly.

I

I'll check again tonight. Currently at work with a ton of stuff I need to take care of 🙂

@edvin ok. if you get a github fork going, i'll pull from it and test it too. what is the test you're running? i'm testing the lower left count

@carlw I haven't created a PR or anything because I've been experimenting a lot. Will create a fork once I have something solid.

@edvin if it's available publicly, I can just work with your branch

@edvin in tornado, what is the logic or key that would cause me to recycle a list fragment?

@edvin i know you have to get going. just put the branch up publicly and i'll pull from it. don't worry about the pull request if you get a break, look over my console and make sure that that's what you're expecting. i'm not suggesting that RAM is a problem with the extra fragments, just that the list seems to be recreated with new fragments which retain their link to the model My console shows 14 fragments created and linked to 3 model elements (a,b,c). None are recycled.

@carlw That's as expected if the ListView shows about 14 fragments (maybe 12).. With only 3 model elements, I would think that only a handful of the fragments are ever used to display those items. There should be no need to do anything with these, think of the fragment as the node representing each cell. Basically, the fragments are managed by JavaFX, since it manages the instantiation of the cells. I think this is working as expected. Sorry gotta run, will get back to you tonight!

@edvin talk to you then