How can we improve the Windows dev platform?

Add Markup Extensions to (and Improve) WinRT Xaml System (System.Xaml Parity)

Much effort was made in WPF Xaml Serialization to decouple it from the presentation assemblies and moved into its own assemblies, System.Xaml, and System.Windows.Markup.

This Xaml System had it's own serialization/deserialization mechanism in XamlServices class. Furthermore, this Xaml system had a very powerful component/concept that is conspicuously absent in WinRT: Markup Extensions.

Markup Extensions are found in the following Xaml Systems:
- WPF
- Silverlight 5
- Xamarin.Forms (notably NOT a Microsoft technology, but recognizes their power nonetheless)

This feature is to ask for Xaml serialization featureset parity with WPF/System.Xaml. That means:
- Custom Markup Extensions
- XamlServices.Load and Save
- All default system markup extensions "{x:Null}, {x:Static}, etc." found in WPF/Silverlight5.
- IProvideValueTarget interface
- INameScope interface
- ... and more!

YEAH!!! XAML!!! WHOOOOOOOOOOO!!!

326 votes
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Mike-EEEMike-EEE shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    An always happy Friday as I just got the TFS complete email :) As this hasn’t hit an insider preview SDK, i’m going to mark this still as “working on it” still BUT … this will be coming to an insider build near you!

    This item heart is markup extensions. There is one item that will not be there however that is relevant to markup extensions, IServiceProvider. I created a new item for that but we are working on this item [https://wpdev.uservoice.com/forums/110705-universal-windows-platform/suggestions/19416094-iserviceprovider-for-markup-extensions-for-wpf-par]. We have created a new one and we are working on that (that includes IProvideValueTarget and INameScope) but feel we have enough to ship this and mark this larger work item done and we do point out in reference to more work items need to happen, namely the work around IServiceProvider.

    Also XamlServices.Load / Save isn’t directly related to markup extenstion so we’re viewing that as out of scope. Also per documentation, System.Windows.Markup.XamlReader and XamlWriter are the preferred ways to do this, which are in UWP. (https://msdn.microsoft.com/en-us/library/system.xaml.xamlservices(v=vs.110).aspx and https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.markup.xamlreader

    54 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      Submitting...
      • Anonymous commented  ·   ·  Flag as inappropriate

        There is old lack of native XAML
        https://wpdev.uservoice.com/forums/110705-universal-windows-platform/suggestions/7232264-add-markup-extensions-to-and-improve-winrt-xaml

        I had seen post about custom markup extensions on UWP apps but it is not work at all
        https://msdn.microsoft.com/en-us/windows/uwp/xaml-platform/customresource-markup-extension
        At first, I install latest version of Visual Studio and try to create custom extension for localization but described in your article way with derive from CustomXamlResourceLoader class doesn't work :(
        I still have compiler errors:
        Cannot assign 'Localizing' into property 'Text', type must be assignable to 'String'
        Type 'local:Localizing' is used like a markup extension but does not derive from MarkupExtension.

        Second, please, see ABindingExtension class and read the article about it
        http://makeloft.xyz/lessons/xaml/custom-binding-extensions

        public abstract class ABindingExtension : Binding, IValueConverter
        {
        protected ABindingExtension()
        {
        Source = Converter = this;
        }

        protected ABindingExtension(object source) // Source, RelativeSource, null for DataContext
        {
        var relativeSource = source as RelativeSource;
        if (relativeSource == null && source != null) Source = source;
        else RelativeSource = relativeSource;
        Converter = this;
        }

        public abstract object Convert(object value, Type targetType, object parameter, CultureInfo culture);

        public virtual object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture)
        {
        throw new NotImplementedException();
        }
        }

        This class very good and memory safe alternative for classical MarkupExtension. This approach works even on old Windows Phone Silverlight where is not MarkupExtension class.

        I tried to apply this way to UWP but there are two artificial limitations of XAML-parser.

        Look at sample

        public abstract class ABindingExtension : Binding, IValueConverter
        {
        protected ABindingExtension()
        {
        Source = Converter = this;
        }

        protected ABindingExtension(object source) // Source, RelativeSource, null for DataContext
        {
        var relativeSource = source as RelativeSource;
        if (relativeSource == null && source != null) Source = source;
        else RelativeSource = relativeSource;
        Converter = this;
        }

        public abstract object Convert(object value, Type targetType, object parameter, string culture);

        public virtual object ConvertBack(object value, Type targetType, object parameter, string culture)
        {
        throw new NotImplementedException();
        }
        }

        public class Localizing : ABindingExtension
        {
        public override object Convert(object value, Type targetType, object parameter, string culture)
        {
        return "test"; // return value by key
        }
        }

        For example
        <Control>
        <Control.DataContext> // is object
        <Localizing/> // called Convert method like expected!
        <Control.DataContext>
        </Control>

        output => Works fine!
        But

        <TextBlock>
        <TextBlock.Text> // is string
        <Lokalizing/>
        <TextBlock.Text>
        </TextBlock>

        output => Cannot assign 'Localizing' into property 'Text', type must be assignable to 'String'

        Also
        <Control DataContext="{local:Localizing}"/>

        output => Type 'local:Localizing' is used like a markup extension but does not derive from MarkupExtension.

        Pease, check this artificial limitaions for Bindings becouse all works fine, but only XAML-preprocessor get errors!

        P.S. May be you will be interested by SwichConverter and some other power improvements for XAML and MVVM

        <Grid.Resources>
        <SwitchConverter x:Key="NumberSwitchConverter" Default="Hello">
        <Case Key="0" Value="Zero"/>
        <Case Key="1" Value="One"/>
        </SwitchConverter>
        </Grid.Resources>
        <TextBlock Text="{Binding Number, Converter={StaticResource NumberSwitchConverter}}"/>

        Number==0 => out: Zero
        Number==1 => out: One
        Number==2 => out: Hello

        Please, see code samples and Aero Framework library
        https://onedrive.live.com/?authkey=%21AMT2QVotfWTReos&cid=C8D6E2F8053DDCFB&id=C8D6E2F8053DDCFB%2123902&parId=C8D6E2F8053DDCFB%2123896&action=locate

        Thanks!

      • LarryLarry commented  ·   ·  Flag as inappropriate

        Without this, I cannot bind a Uid in a data template (if that is incorrect, someone please let me know!).

      • MysticTazMysticTaz commented  ·   ·  Flag as inappropriate

        Additionally, WinRT Xaml REALLY needs x:Type and support for TypeConverter's, which WinRT also doesn't have yet.

      • Mike-EEEMike-EEE commented  ·   ·  Flag as inappropriate

        Additionally, this assembly should also be self-contained and distributable, just like System.Xaml. Meaning, we should be able to use this assembly for Xaml serialization no matter where it's needed, whether it is in the client, server, anywhere... just like System.Xaml.

      • Mårten RångeMårten Rånge commented  ·   ·  Flag as inappropriate

        Inheriting MarkupExtension was sadly missing from WinRT (along with other things but lets not get into that). I have used it to define "aliases" for different styles of bindings to reduce code duplication in xaml. Instead of writing {Binding Path=XYZ, Format={}{0,0.00}, Mode=TwoWay,ValidateOnError=true} everywhere I could make an alias: {b:BindToAmount XYZ}. Achieves less redudancy and clearer semantics.

      • kTAMURAkTAMURA commented  ·   ·  Flag as inappropriate

        Silverlight has already supported the custom markup extension.

        Because Static, DynamicResource and DataType markup extensions connot be use on metro style app, at least, it is nessesary to support custom markup extension for metro style app.

      1 3 Next →

      Feedback and Knowledge Base