there's isn't a need to have reference for the view (or the controller) in the model

in the fluxfx case, data is pulled from the model but it may be initiated independently from the view -- say a refresh() button

and testable without a view

Fun fact: https://twitter.com/edvinsyse/status/791682486996758529

After talking to @carlw and thinking about the tenant scope some more I think I'll try a solution that will work for the JPro case and also give some manual control over scoping, but it will not be an enterprise feature like scoping is in Java EE for example. Basically you configure a scope for any originating app, view or fragment. Then all injected components will share the same scope unless you specify a different scope to

inject()

or

find()

. This will be unobtrusive and have a very small footprint and probably easy to understand and reason with. I think we should flag this feature as a beta feature for a while with a warning that the API might change. API-wise it will consist of a variable in component and the parameter to

inject()

and

find()

. That's basically it. I tried this approach early on but with another mindset so I was never satisfied with it. By accepting that it will not be everything for everyone, and maybe even just a special feature to support JPro and possibly similar frameworks in the future I came to the conclusion that it is "good enough" at least for now. I really need to get back to documentation and screencasts and also the kitchen sink app, so I will try to implement this tomorrow in a feature branch and see how it feels.

I can't wait to see it. For some added inspiration regarding scope, check out what these guys are doing in the mvvmFX project on GitHub. https://github.com/sialcasa/mvvmFX/blob/develop/examples/contacts-example/src/main/java/de/saxsys/mvvmfx/examples/contacts/ui/master/MasterViewModel.java

@carlw @edvin - the mvvmFx scope concept is based on parent child relationships (the child inherits the parent view's scope unless configured otherwise).

@gtnarg I think we're looking for something more general here. I've been speaking to @edvin about MDI (multiple document interface) which would be identical View objects receiving different injected Model objects. This is a pattern for apps like MS Word and IntelliJ IDEA.

Regarding the scopes...it seems like this might be useful for the just-released Mac that operates a second Stage as a set of app-specific function keys.

For example, say you have a project open to a source file and another open to a version control interface, there would be different function keys available on the touchbar based on who has the focus.

@carlw - I agree - just trying to point out the difference 🙂

although based on Edvin's explanation - by passing parameters to inject() or find() you should be able to achieve the same result in a more flexible way

@carlw Thanks, actually I think this might be a bit similar. I also think we can use this for MDI. I hope to have something working up and running soon.

To start a new scope you can do something like

val myScope = Scope(); val viewInNewScope = find<MyView>(myScope)

Scope is an open class, so you can subclass it to pass arbitrary data around together with the scope if you want. You can even use the scope to hold your state, which is very nice. Just put the

ViewModel

inside the scope 🙂

We might have a scopeStore of some kind also, so it's possible to query for scopes.

So you can say "Give me all scopes for customer 42" for example.

If you open a new stage, it can live inside the scope as well.

You should be able to keep the same find() call signature. That way, it would be up to the artifacts themselves to define the scope they belong to. Ex, by default View is -at-Singleton, Fragment is -at-Prototype. Then, you could do something like this. annotation class ProjectScoped @ProjectScoped class ProjectViewModel { val projectTitle : String by inject()

And have everyone who needs projectTitle use the same scoping value...inject() and find() work without modification.

Ex, @ProjectScoped class ProjectDetailViewModel { val projectTitle : String by inject()

@edvin for @gtnarg 's #190...I worked out an example the replaces some of the containers in the existing Form/Fieldset/Field classes in favor of a GridPane with rows and columns. This seems to work naturally as the decision whether or not to resize a row can be made on a field-by-field basis. No listeners for width and height are needed. If you think this is worth pursuing, I can develop the idea further to accept a set of input controls (rather than the single TextField here), handle orientation, and add in some temporary typesafe builders.

@User uploaded a file: Alt. Take on Form/Fieldset/Field and commented: No listener version of Forms.kt

I don't mind doing more work even if it gets thrown away as it's helping me learn Kotlin.

I finally found 30 consecutive minutes with no interruptions and I'm happy to say that JPro is now running perfectly with the new scope system. I met one challenge I just hadn't thought about.. If you use

find()

inside init or inside the

override val root =

expression, you will call find before the framework would have a chance to call

component.scope = theScope

. I solved this with a threadlocal, so that the value can be set before

newInstance()

is called. This seems to work like a charm.

Basically, the only change to

Component

to support this is this line:

@User uploaded a file: Component changes to accomodate Scope

Then

find()

simply calls

FX.inheritScopeHolder.set(theScope)

before it instantiates the component. Anybody have a nicer name than

inheritScopeHolder

for me? 🙂

To support JPro we now just have to create a unique scope everytime the app class is initialized. I did it like this:

@User uploaded a file: Custom JPro init app