views:

1048

answers:

1

I have an IValueConverter implemented class and I need it to be injected using my DI container (Ninject).

The problem is, in XAML, there's no immediately obvious way to get control over the instantiation of the Converter object.

So my XAML contains a line something like this:

Source="{Binding Path=CurrentMessage, Converter={StaticResource ImagePathConverter}}"

Where, the ImagePathConverter will be created for me.

I suppose I could create a "service locator" static class and call it to resolve my dependency and change the StaticResource to a property "MyServiceLocator.TheImageConverter", but that makes me want to vomit.

I'm looking to Prism, as I hear it has answers for this. But I've trundled my way through tutorials and code a few times without finding an obvious simple isolated answer to this issue. Although I am happy to use it.

I am hoping this question can be answered with a few snippets of code that specifically target the code supplied - and perhaps a supporting link to an example. Not simply a recommendation to take a look somewhere (sorry to say this but I've seen this done elsewhere and found it annoying)

Also, very importantly, assume that the XAML does not have a code-behind - and that I cannot use one. I'm creating a skin and do not want a code behind. So I cannot set a class variable in the class constructor and reference it. Maybe that's unreasonable, I'm not sure yet.

+2  A: 

A common way to handle this is for your converter to also be a MarkupExtension. That is:

public class MyConverter : MarkupExtension, IValueConverter

Your ProvideValue() method can return an instance of your converter, thus allowing you to use it like this:

Source="{Binding CurrentMessage, Converter={local:MyConverter SomeParameterToConverter}}"

This isn't really anything to do with DI, but it does address your requirement to eliminate the code behind. I don't really see the point of having converters registered with your DI container.

HTH, Kent

Kent Boogaart
Thanks, it's a fair concern about converters. By not seeing the points of having converters registered with the DI container, I think your assuming that the DI container is just being used to 'new up' objects.The point is that the Converter class in question has other dependencies that can only be resolved by the DI container (eg "configuration" objects registered in singleton scope)
PandaWood
I think this is a good answer, when I can fix the error 'Missing XmlNamespace, Assembly, or ClrNamespace in Mapping instruction' I'll come back to it (ie despite adding xmlns:local="clr-namespace:MyNamespace"
PandaWood
Got it! Fixed the error and it works nicely. I still needed to call my DI in a service locator fashion in the ProvideValue method, but I don't think there's any way around that)
PandaWood