Allow services to be registered as resources

[mauroservienti]

Something like:

var conventions = s.GetService(typeof(IConventionsHandler));
this.Resources.Add("ConventionsHandler", conventions);

on boot completed

[micdenny]

what's the purpose of this?

[mauroservienti]

The idea, and I'm facing the issue right now, is that there are scenarios where you need to able to use some service that comes from the IoC container inside a custom DataTemplateSelector but the DataTemplateSelector lifecycle is managed by WPF and not by us.

[micdenny]

I see.... in fact this is not an easy task and your idea is in fact one possible solution to avoid service locator.

isn't there any service container/provider that wpf using internally that we can use as well? an implementation of IServiceProvider, I mean it will not inject dependencies, but if we can have access to a provider already present in wpf, we could use it for this purpose.

[mauroservienti]

isn't there any service container/provider that wpf using internally that we can use as well?

no, nothing, or if it exists it is not public :cry:

[micdenny]

what about providing a static service locator in radical?

Radical.ServiceLocator.Current.GetService<T>()

I'm just pushing for a different way because pushing every component as resource smells to me, and probably is something that radical should not "radically" resolve :smile: instead providing a clear access to the container could be enough for a developer to implement all other kind of extension like data template selectors.

[mauroservienti]

In my view a static service locator is evil :smile:, my original idea was to enable users to do something like:

bootstrapper.ExposeAsResource<ISomething>();

[mauroservienti]

The idea is that this:

bootstrapper.ExposeAsResource<ISomething>();

similarly to https://github.com/RadicalFx/Radical.Windows.Presentation/pull/26 the above will add to the application resources a resource named "ISomething", the interesting thing is that now one could write:

<TextBlock rg:RegionService.Region={rg:MyCustomRegion Name=Foo, Something={StaticResource ISomething}} ... />

reducing to zero the needs to expose statics from App.Current and friends.

[micdenny]

In my view a static service locator is evil

I agree, using the locator you would end-up with a coupled implementation, instead using the resource way not.

great to have it exposed everywhere in the xaml, cool, you convinced me :smile:

:+1:

[mauroservienti]

This issue was moved to RadicalFx/Radical.Windows.Presentation#49