Wednesday, 8 April 2009

Intercepting xaml DataTemplate of a given DataType

Since a few months I am working on a project where we use integrate WPF with and IOC, Castle Windsor (through the extension of the Composite WPF Contrib).

One of our xaml file would look like this:
<ResourceDictionary xmlns="

<converters:booleanenumconverter key="YYYConverter">
[snipped other converters]
<DataTemplate DataType="{x:Type
[snipped template xaml]
I wrote a couple of interceptors (inheriting from IInterceptor and implementing Intercept), but when I try to use them resolving the presentation model, the xaml DataTemplate resolves to a string (the name of the generated proxy, something as IMyFormPresentationModelProxy1de831fc74a341249b67...), not to the instanced object (which stepping in in debug I can see it is registered and then created and then also proxied correctly, as far as I can understand). This is exactly the same behaviour we get if we try to use the interface (i.e. setting the DataType to "{x:Type Presentation:IMyFormPresentationModel}" we get a string as well instead of the object).

Using the .Net reference source symbols (and/or deblector) I have been trying to step in on the exact bit of code which is setting that string instead of the correct proxied object or even the underlying instanced object, but with no luck so far.

I do think the issue may be with the xaml engine being unable to match the proxied type with the DataType of the DataTemplate, and I found out the .Net framework may perform that using the TypeExtension/MarkupExtension/DataTemplateSelector classes and possibly some implementation of the IXamlTypeResolver interface. From a quick search, I found out nowadays people is using those mostly to provide some support for generics in xaml (see i.e. "How To Get ParserContext" or "Limited generics support in Xaml").

From a purely theoretical point of view, I don't like much the idea to have to modify the xaml files to be able to intercept them, so I am not absolutely sure I have been missing something.

Before trying to spend some time on that (i.e. writing our own TypeExtension), I thought it could be better asking around if there is someone with previous experience or also some insight on this kind of scenario, so I have been posting a similar text to various newsgroups and mailing lists.

Last but not least, although I don't guess this is a Windsor bug (or at last I cannot yet see why it should be :)), we are using Castle project assemblies built from the revision 5380 of the 19th October 2008 in the trunk.

No comments: