New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CTL-781: Support parent / child IoC containers #770

Open
GeertvanHorrik opened this Issue Nov 23, 2015 · 5 comments

Comments

Projects
None yet
2 participants
@GeertvanHorrik
Member

GeertvanHorrik commented Nov 23, 2015

Jira issue originally created by user @GeertvanHorrik:

We need this in Orc.FilterBuilder and Orc.WorkspaceManagement. For now we have solved it with tags, but best is to created scoped containers where there is a fallback:

ServiceLocator

  • child 1
  • child 2

If a type cannot be found on a child, fallback to parent.

@stale

This comment has been minimized.

Show comment
Hide comment
@stale

stale bot Apr 29, 2018

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

stale bot commented Apr 29, 2018

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the wontfix label Apr 29, 2018

@lipchev

This comment has been minimized.

Show comment
Hide comment
@lipchev

lipchev Apr 29, 2018

Hello,
I have a question that may pertain to this issue- or maybe it is simply a misunderstanding on my part:
I have several screens, each displaying lists of the same type of user control, but requiring a different set of DI components injected into the children(per screen- not per instance).
In the child's view model I would ideally like to have my dependencies injected via constructor parameter(along with the model), while the registrations are done on app level. However having failed to achieve that I resolved to using the RegisterDependencyResolverForType(typeof(MyChildViewModel), rootResolver)- when opening the screen- which overrides whatever the previous screen had set as dependencies, and having all of the services registered to rootResolver(the resolver for each screenVM-type) on app start- the screenVMs do not deal with any of the children's services- they just display children. However they do become aware of the types of child view models(as they require the explicit resolver registration to occur in the screen instance). Also having two screens display same type of children at the same time with different services injected into them- would seem to require a custom resolver.
It would have be nice to have the possibility that DI's in a child view model fail-back to the parent's VM dependency-resolver (or some parent scope). Or maybe there is already a way to achieve this that I'm not seeing?

lipchev commented Apr 29, 2018

Hello,
I have a question that may pertain to this issue- or maybe it is simply a misunderstanding on my part:
I have several screens, each displaying lists of the same type of user control, but requiring a different set of DI components injected into the children(per screen- not per instance).
In the child's view model I would ideally like to have my dependencies injected via constructor parameter(along with the model), while the registrations are done on app level. However having failed to achieve that I resolved to using the RegisterDependencyResolverForType(typeof(MyChildViewModel), rootResolver)- when opening the screen- which overrides whatever the previous screen had set as dependencies, and having all of the services registered to rootResolver(the resolver for each screenVM-type) on app start- the screenVMs do not deal with any of the children's services- they just display children. However they do become aware of the types of child view models(as they require the explicit resolver registration to occur in the screen instance). Also having two screens display same type of children at the same time with different services injected into them- would seem to require a custom resolver.
It would have be nice to have the possibility that DI's in a child view model fail-back to the parent's VM dependency-resolver (or some parent scope). Or maybe there is already a way to achieve this that I'm not seeing?

@stale stale bot removed the wontfix label Apr 29, 2018

@GeertvanHorrik

This comment has been minimized.

Show comment
Hide comment
@GeertvanHorrik

GeertvanHorrik Apr 29, 2018

Member

@lipchev The IoC components inside Catel do support nesting and resolving inside a scope, but it's hard to apply this inside a user control view. If you can upload a simple (!) demo / repro with requirements, I might be able to implement something like this if we need something similar for our own needs.

Member

GeertvanHorrik commented Apr 29, 2018

@lipchev The IoC components inside Catel do support nesting and resolving inside a scope, but it's hard to apply this inside a user control view. If you can upload a simple (!) demo / repro with requirements, I might be able to implement something like this if we need something similar for our own needs.

@lipchev

This comment has been minimized.

Show comment
Hide comment
@lipchev

lipchev Apr 29, 2018

Thank you,
here is a simple(!) example of what I would like to achieve: 1 control (PersonsList) and two sub-contexts for birthday & wedding parties- each
one contains an instance of GiftSelectionView, however I would like to inject a different type of IGiftShopService into each of them (BirthdayShop & WeddingShop resp.)
Ideally all registration is done in app.xaml.cs.
FamilyScope.zip

lipchev commented Apr 29, 2018

Thank you,
here is a simple(!) example of what I would like to achieve: 1 control (PersonsList) and two sub-contexts for birthday & wedding parties- each
one contains an instance of GiftSelectionView, however I would like to inject a different type of IGiftShopService into each of them (BirthdayShop & WeddingShop resp.)
Ideally all registration is done in app.xaml.cs.
FamilyScope.zip

@stale

This comment has been minimized.

Show comment
Hide comment
@stale

stale bot Jun 28, 2018

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

stale bot commented Jun 28, 2018

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the wontfix label Jun 28, 2018

@stale stale bot closed this Jul 5, 2018

@GeertvanHorrik GeertvanHorrik added pinned and removed wontfix labels Sep 6, 2018

@GeertvanHorrik GeertvanHorrik reopened this Sep 6, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment