Using ControlTemplate, DataTemplate, etc. only in C# code?

[idexus]

I'm working on a library to fully support WinUI 3 in code using fluent methods, without having to use XAML. The only problem I have is with classes like DataTemplate, ControlTemplate, etc. that I can't create without this weird XAML workaround.

XAML workaround

namespace CodeMarkup.WinUI
{
    public delegate void TemplateBuildMethodWithParent<T>(T root, FrameworkElement parent) where T : FrameworkElement;
    public delegate void TemplateBuildMethod<T>(T root) where T : FrameworkElement;

    public abstract class FrameworkTemplate<TTemplate, TRoot>
        where TTemplate : FrameworkTemplate
        where TRoot : FrameworkElement
    {
        public static implicit operator TTemplate(FrameworkTemplate<TTemplate, TRoot> frameworkTemplate) => frameworkTemplate.xamlFrameworkTemplate;

        TTemplate xamlFrameworkTemplate;
        public FrameworkTemplate(TemplateBuildMethodWithParent<TRoot> build)
        {
            var guid = Guid.NewGuid().ToString();
            FrameworkTempateManager.HandlerMethodsWithParent[guid] = (root, parent) => build(root as TRoot, parent);
            CreateXamlFrameworkTemplate(guid);
        }

        public FrameworkTemplate(TemplateBuildMethod<TRoot> build)
        {
            var guid = Guid.NewGuid().ToString();
            FrameworkTempateManager.HandlerMethodsWithoutParent[guid] = root => build(root as TRoot);
            CreateXamlFrameworkTemplate(guid);
        }

        void CreateXamlFrameworkTemplate(string guid)
        {            
            var xamlControlTemplateString =
$@"<{typeof(TTemplate).Name}
    xmlns=""http://schemas.microsoft.com/winfx/2006/xaml/presentation""
    xmlns:root=""using:{typeof(TRoot).Namespace}""
    xmlns:manager=""using:{typeof(FrameworkTempateManager).Namespace}"">

    <root:{typeof(TRoot).Name} 
        manager:{typeof(FrameworkTempateManager).Name}.MethodId=""{guid}"" 
        manager:{typeof(FrameworkTempateManager).Name}.TemplatedParent=""{{Binding RelativeSource={{RelativeSource TemplatedParent}}}}""/>

</{typeof(TTemplate).Name}>";
            xamlFrameworkTemplate = (TTemplate)XamlReader.Load(xamlControlTemplateString);
        }
    }

    public class ControlTemplate<TRoot> : FrameworkTemplate<ControlTemplate, TRoot>
        where TRoot : FrameworkElement
    {
        public ControlTemplate(TemplateBuildMethodWithParent<TRoot> build) : base(build)
        {
        }
    }

    public class DataTemplate<TRoot> : FrameworkTemplate<DataTemplate, TRoot>
        where TRoot : FrameworkElement
    {
        public DataTemplate(TemplateBuildMethod<TRoot> build) : base(build)
        {
        }
    }
}

Isn't there some solution to create these objects only in code?

e.g.

ControlTemplate itemTemplate = new ControlTemplate<Grid>((root, parent) =>
{
     // Create  content
});

and

DataTemplate itemTemplate = new DataTemplate<Grid>(root =>
{
    // Create  content
});

then using fluent API I can do something like this:

new ItemsRepeater()
    .ItemsSource(percentDataList)
    .Layout(new StackLayout {Orientation = Orientation.Vertical})
    .ItemTemplate(dataTemplate) 

// data template declaration (static field)

readonly static DataTemplate dataTemplate = new DataTemplate<Frame>(root =>
{
    root.Content = new Border()
        .Background(e => e.ResourceKey("SystemChromeLowColor").Source(root))
        .Margin(4)
        .Size(400, 20)
        .Child(
            new Rectangle()
                .HorizontalAlignment(HorizontalAlignment.Left)
                .Fill(e => e.ResourceKey("SystemAccentColor").Source(root))
                .Width(e => e.Path("Percent").Convert<double>(d => d * 4))
        );
});

[DarranRowe]

The best suggestion I have is to basically copy what the Xaml compiler does.
The Xaml compiler does output source files. For C#, it should output the generated .cs files in the obj directory.

[marcelwgn]

Thank you for your very detailed and lengthy explanation on the difference and context of XAML to XBF and for correcting me on the matter what XBF. However this does not answer the question of how to initialize certain XAML elements such as ControlTemplate or DataTemplate in C# does it? After all, you said XAML/XBF is a way to tell the runtime how to initialize things, the question asked though was how to not use XAML to initialize everything but use pure C#.

@idexus I'm surprised that creating styles works that easily, really cool seeing that project! However, you still haven't found a solution for *Template constructs such as DataTemplate right? I think there really isn't a solution for this, during the past few years contributing to this project, I think this topic came up once or twice and everytime we resorted to creating templates using XAMLReader.Load.

---

@DarranRowe On a side note, while this is my purely my opinion, I think filling your explanations with words/sentences like "easily" and "we know" and similar constructs might be seen as arrogant or condescending.

[DarranRowe]

@chingucoding
I wonder if you missed the biggest point of the posts. By seeing what the Xaml compiler does, you can do it yourself. You can query the object tree at runtime. You can query the controls at runtime. Why is it problematic to write an application that lays out the xaml in such a way to achieve what you want, and then query the properties of the controls?
So to directly answer the question, you use a running instance of the object tree to provide answers.

Also, for that side note. I do not see "easily" or "we know" in my post. The only "obviously" I have is in relation to Application.LoadComponent, this is backed up by the fact that I listed Xaml compiler generated code that directly references this. So I do not see why using this when I have been laying out the steps that I took to get there is that problematic. Unless you are referring to the "as you know" in relation to the .xaml files not being part of the final layout. In which case I will state that you referenced this yourself in your second reply.

[marcelwgn]

@DarranRowe Quite honestly, I think this is not a solution here. What actually does the XAML Compiler do?
Does it create XBF Files? Then it does not help with creating a DataTemplate purely using C#.
Does the XAML Compiler generate C++ or C# Files that we should inspect? In that case, you already said, it just glues together the XAML World and the non XAML world which does not help because some stuff is created using XBF (at least I can't find the code that would create the control in the generated files beside Application.LoadComponent).
Lastly, taking a running instance of the object tree doesn't help you how it was instantiated does it? After all, @idexus and I would love to know what C# code we can use to create a DataTemplate without having to resort on any XAML Compiler during runtime.

So to conclude my view of your solutions, I am unable to find the solution to the problem, that is how to create a DataTemplate in C# without using the XAML Compiler Infrastructure during runtime given the comments you gave. I was unable to find that code in the generated files of a project and I was also unable to deduce this from a running app by inspecting the tree. But maybe I am missing some crucial detail here that would help find the solution to the question asked?

---

Regarding the side note, while you are right you did not say "we know", you did say "easy" in one of your earlier replies and "obviously" also is in the same lane of words but that's nitpicking and beside the point. It is your choice what to do with this feedback, if you think this was not righteous of me to point that out, then that's also fine. I sincerely hope that I did not offend you with these comments.

[idexus]

I am similarly unable to find a solution to the problem based on what @DarranRowe writes. The main problem is that when you define a *Template, you have no idea what's in it until you instantiate it.

Here we need a solution to this fairly simple problem directly in the library, not some XAML workaround. I know the Microsoft world is the XAML world these days, but not everyone wants to build applications using this technology. Maybe someone who decides will hear it.

[DarranRowe]

I see, that is unfortunate.
I will have to bow out then. This would require a lot more work than I am willing to put in on my rest days, and I am currently too busy during the week to be able to put in the required work.
I hope that someone else gives you a satisfactory answer.

There is also one major thing that I feel needs to be corrected. This was never about providing Xaml workarounds. The fact that things were seen this way shows that I was not the right person. This had a much simpler goal. If you understand how the Xaml runtime does things, then it means that you understand the basic concepts. The result of this is that you then understand how to write the exact same thing in code. Figuring things out was only ever a means to an end.