@ron I've been using something like the event bus to handle the Model -> ViewModel communication. The ViewModel -- which has a bound property to the UI -- receives an update which modifies its value and the UI by extension. Watch for cascading updates if you're binding twice.

yeah I was thinking about using the bus

I just used it this afternoon to communicate between threads

my suggestion expands on that to work at the logical level (not just the communications level). ViewModel knows of Model, but not the other way around. Also, I have a coarsening data granularity. I'm using a domain object in the model and individual fields in the viewmodel.

@carlw OK 🙂

@User uploaded a file: Option 1 - keep the ugly in the model

@ron Option 1 is to simply move that logic into the

GroupModel

. Now you can keep your UI code clean and just bind to the entries property.

@ron I think we might be able to support this automatically though, i.e binding to an ObservableList. That would be pretty neat.

@ron I'd like to investigate this. Hopefully I can get it done before the 1.5.9 release. Wanted to do it tomorrow 🙂

sure go ahead 🙂

I dont mind using it

Hi. I'm trying to use `Fragment`s to build my views from several parts, but they're not showing up. For example, in the main view (root is a BorderPane), in

init

I have this

left {
                ComponentView()
            }

where `ComponentView`looks like this:

class ComponentView : Fragment() {
    override val root = ScrollPane()

    init {
        with(root)
        {
            text("Available symbols")
        }
    }
}

Obviously I'm missing something, anyone got any hints?

Use

left(ComponentView::class)

Oh, that works.

Using this syntax, TornadoFX will automatically find the UIComponent for the class and either load the instance (if it's a view) or create an instance (if it's a fragment)

Ok. But what is the actual fault with how I did it?

You just created a

ComponentView

and didn't do anything with it. In your case, you could have done

left {
    this += ComponentView()
}

oh. Silly me. 🙂

Blinded by the elegance of the builder pattern 🙂

Thanks!

Yeah, that gets me every now and then too 🙂

Design question: I'll be doing a lot of drag-n-drop. Will it hurt if I separate my app into several views and then attempt to do drag-n-drop between these views? I'm thinking it doesn't really matter as long as I do the "logic" for the drag and drop events in the view models/controllers.

That's my assumption as well, but I haven't tried it yet

Ok. I'll try with separate views and hope for the best 🙂

Let me know how it goes. My current project will eventually be using something similar once I get more into the UI design (I've been working on internals for a long time 😛 )

Sure thing.

@Ruckus - do you have any updated video of the Christmas display for this year?

@gtnarg Ready for an update of the CA / US blackout of 2003?

@gtnarg hopefully Kotlin eliminates sign errors that could reverse the big pull of current

@gtnarg No, but we'll be spending Christmas with my parents (where we do the display), so I'll see if they have a good recording this year.