@carlw You mean if you're missing a dependency? Remember than any injectable will be automatically created when needed, it's like @ApplicationScoped in Java EE.

So if it's injectable, it will always be available. But if it needs data to display something, that's another matter (and might be considered a programming error even, except for very special cases). Bottom line is that you should always be able to show the object graph without data, same as FXML.

i haven't done DI yet with tornado. I'll post some code later to try to articulate what I'm describing. IN guice or spring terms, I'm describing a config XML or abstract module that needs to be provided in a context where not everything is wired up from just default constructors

I used guice in some javafx programs and because of that we built the

by di

construct

@carlw OK, I understand. Normally, TornadoFX DI deals in Views, Fragments and Controllers. As long as they are on the classpath, they require no configuration to work. If you use the

di

construct @ron mentions, you would need that container configuration. I've written pretty large applications and never had any need for any external di though, but I see your point.

i'd like to chat about the DI more. i haven't gotten into "by di" yet but would like to I'm going to concentrate on getting the TODO app put together with the builders, starting with Ron's branch later in the evening (my time)

@carlw Great! DI was given very little attention up until now, since the framework has built in support via

inject()

and I just haven't seen any use cases apart from legacy apps, but I'm keen to improve it none the less 🙂

Wow, this

ItemViewModel

is extremely handy. The

empty

property can be used to hide the editor in a master/detail construct so easy:

@User uploaded a file: Untitled

Is that something you want in the todo app?

there is a function toggleEditMode() now

@edvin the choseDirectory works great, thank you.

@carlw No, I don't think that fits, since the model will not be empty as long as you have an item to show.

@jchildress Great, thanks for letting me know 🙂

@carlw I got rid of the toggleEditMode() in my version, did I show you that?

@carlw All the other sample apps did not leverage the editing capabilities of ListCell, because it's not possible to edit a FilteredList. But I changed to using SortedFilteredList, which I made editable 🙂

@carlw Oh, nice! I just changed to using the new

ItemViewModel

in the todo app, and it made the whole thing much nicer. Now the model and fragment looks like this:

@User uploaded a file: Untitled

@carlw All I need to do now is

model.itemProperty.bind(itemProperty)

and the view model will always point to the item the fragment represents.

@carlw I did some other changes also, since you need the

SortedFilteredList

to leverage the editing capabilities of listview

@edvin that's actually pretty different than what I have and it's different than the zip you gave me earlier

can you upload yours so that I can keep track better

?

@carlw Yeah, I'm constantly playing with new stuff 🙂

@carlw I will!

NP, let's git-ify it so I can keep up

maybe start with a fork, overlay your current version, and if it's working, send it up

All right. Will let you know.

i did away with the Controller class since it just delegated to TodoItemModel. I upgraded the model component to be a true Component() Injectable so that the view could get at it

@carlw Great! Haha, I actually just did the opposite, removed the TodoItemModel. The main issue is that the classes were just overlapping and adding complexity without value.