interesting to see that this guy brought back the builders in his project https://github.com/netopyr/reduxfx

I'm having a hard time understanding that this is a good idea, but it seems interesting 🙂

builders used correctly can be insanely powerfull

@edvin some of the projects i've been looking at lately (mvvm, fluxfx, and now this one) point to a need for something more than binding. these projects have an alternate notification mechanism to keep things decoupled. I've sent some updates around myself (not with TornadoFX) so i think they're worth looking at

@edvin - are you familiar with Redux in javascript?

sending updates around ? like an evenbus like system?

Re: Redux - to provide some context for this architecture this video is worth watching:

@ron yes, but in addition to binding. windows wpf mvvm has some good documentation on the idea. WPF has XAML (FXML), code behind (JavaFX Controller), and databinding (Bindings), but still uses some additional property change events

This is a good reference point for MVVM. It could easily work with TornadoFX. https://msdn.microsoft.com/en-us/library/ff798384.aspx

@gtnarg I read a little about it. It seems like a worth while idea since the DOM is so slow. Virtual DOM has been utilized by many frameworks lately, but JavaFX just doesn't suffer from the same problems, so shoehorning the same solution onto a JavaFX app will not yield the same benefits. You'll just end up with an unnatural development flow IMO.

@carlw Absolutely 🙂 Both MVVM and MVC should work fine. When the kitchen sink is up we should definitely add some MVVM samples and possibly adjust support for it in the framework.

Bah, apparently we have plans for Halloween. They seem to not include me spending the evening programming. 💣

@edvin - I agree with your observation about the DOM/performance not applying to javafx. I'm interested in seeing where it goes - as it "might" (i.e. still to be convinced) make application state more understandable in certain situations...

@gtnarg Possibly. In any case it would be interesting to compare some code. I think one of the things JavaFX really has working for it is the binding support and not leveraging it would be a travesty 🙂 That's why we just try to make that part easier to work with while not hiding it too much in TornadoFX.

Finally got the chance to play with the kitchen sink a little. I wonder if we should make the ViewModel injectable by default. It won't be in the way, and you wouldn't need to remember to implement Injectable manually.

So many nice patterns emerging now 🙂

As long as you are in the same scope, you just do

val model : CustomerModel by inject()

in all the Views and Controllers that need the model. Incredibly neat.

Where are you putting this kitchen sink control you speak of?

@thomasnield I will commit it soon to https://github.com/edvin/tornadofx-kitchensink. I just need to deal with some JPro settings (license etc) that can't be public. That's why I haven't committed it yet.

Okay, no problem. Was just curious if I missed something...

If it's what I think it is, that would be helpful. Holds windows within windows, right?

I'm having some problems with JPro though.. weird stuff happens.

Rendering issues?

Not sure yet.. it suddenly just freezes.

@User uploaded a file:

@edvin What if the user wanted to inject two different versions of the same ViewModel type for some reason? Would it make sense to have some sort of qualifying for injection, or am I over complicating things?

For example, a character creation tool for authors that would allow them to compare two characters side by side, each with a

CharacterModel

?

@Ruckus Then you just pass inn a different scope for those two. If you want to inject two of the same in the same component, just do

val first : YourModel by inject(Scope()); val second : YourModel by inject(Scope())

. It will create a new scope, but you don't need to use it for anything. We might want to have a convenience function for that.

Scopes can also contain models. Then it becomes interesting 🙂

Makes sense. Would that cause issues with JPro?