xaml typeprovider component restriction

[nrolland]

In XamlTypeprovider.fs : createXamlNode we have

                match wpfAssembly.GetType(sprintf "System.Windows.Controls.%s" other) with
                | null -> typeof<obj>
                | st -> st

As I read (fast) the file, it is therefore only possible to instanciate components from that namespace. Do you see any obstacle in augmenting this with different components, potentially in other assemblies ? We'd need to load the dependencies (intercepting System.AppDomain.CurrentDomain.add_AssemblyResolve) , and enhance the XAML parser for getting the namespace.

[forki]

can you please send a pull request?

[rojepp]

Is there a reason why XamlTypeProvider is not using System.Windows.Markup.XamlReader instead of XmlReader? XamlReader has already solved the issue of resolving Xaml Node names to the correct types, no need to do it again?

[rojepp]

@nrolland As I understand the code (haven't verified yet), you can have members in the generated type outside of System.Windows.Controls, but they will be of type Object. Xaml documents do list their dependencies, so we can do a better job here. If I get some free time I'll look into it.

[rojepp]

Argh, I wanted my pull req to be part of this issue instead of creating a new one, #160. I'm not used to GH.

[nrolland]

Do you have a doc mentioning this resolution of Xaml nodes to the correct types? This is interesting.

[nrolland]

Ok I see what you mean, i was out of it, Yeah so the types will be resolved, but the assembly referenced that contain those types might not be loaded I guess. (Not sure I remember everything) So that is why you say it will be of type object, which kind of spoils the typeprovider fun

[rojepp]

My commit fixes this for external controls, i.e. controls not defined in the current assembly. If you create a custom control inside the same assembly that is being 'TypeProvided' it is always going to be of type object, simply because the type doesn't exist yet, so we can't resolve it. :)

[nrolland]

Got it. Ahh.... Multistage execution + a proper composable dependency model... Life would be good...

On Tuesday, November 27, 2012, Robert Jeppesen wrote:

My commit fixes this for external controls, i.e. controls not defined in the current assembly. If you create a custom control inside the same assembly that is being 'TypeProvided' it is always going to be of type object, simply because the type doesn't exist yet, so we can't resolve it. :)

— Reply to this email directly or view it on GitHubhttps://github.com/fsharp/fsharpx/issues/87#issuecomment-10738457.

Nicolas Rolland mobile : +33 6 62 88 42 92

[nrolland]

This is a brilliant change..

[rojepp]

Thanks! :)

[forki]

Can I close this?

[rojepp]

Works for me, but @nrolland should weigh in.

[nrolland]

sure ! thank you robert. it gives me a pretext to look into the specifics of the xamlreader!