Add Input Validation Support to WinUI (UWP and Win32 Desktop) with INotifyDataErrorInfo

[thomasclaudiushuber]

Proposal: Add Input Validation Support with INotifyDataErrorInfo

Summary

Add Input Validation Support with INotifyDataErrorInfo that is supported by x:Bind and Binding. Both Markup Extensions should get a new ValidatesOnNotifyDataErrors property that is - like in WPF's Binding - true by default.

Rationale

Currently UWP does not have any Input Validation built into the platform. But every line of business app requires input validation. It's one of the most important features for a proper enterprise app. There's an entry on uservoice that says this feature will come with WinUI, but I haven't seen anything yet: https://wpdev.uservoice.com/forums/110705-universal-windows-platform/suggestions/13052589-uwp-input-validation

[jevansaks]

@LucasHaines how does this relate to the input validation features you've been looking into?

[LucasHaines]

@jevansaks This is directly related to the Input Validation work i'm outlining.

[thomasclaudiushuber]

Great. If you've any preview stuff to share, I'm happy to try it and provide feedback and thoughts.

[mdtauk]

This is the kind of validation mentioned during Build 2018

`

`

[stevenbrix]

@thomasclaudiushuber how important do you think making this work as part of {Binding} is? I only ask because the technical challenges there are non-trivial, as well as it not being able to work downlevel. Our original idea was to just support x:Bind, which will only require markup compiler changes, and is capable of working downlevel.

Also, we were only planning on supporting the INotifyDataErrorInfo and DataAnnotations paradigm. We weren't intending on adding something analogous to Binding.ValidationRules, and thus didn't feel there was sufficent need for a ValidatesOnNotifyDataErrors.

We'd love to get your feedback as we continue to work on this feature so that it can be done right!

[thomasclaudiushuber]

@stevenbrix

Short answer: Yes, what you think and what you plan sounds great. Just x:Bind is fine, and just INotifyDataErrorInfo is fine too.

Long:

Just x:Bind? 👍

In all WPF-LOB cases I can think of there was always a kind of ViewModel that was known at compile-time, no duck typing, so x:Bind is fine. I wrote {Binding} in this issue too as I thought you can support it to get the same syntax as in WPF. But this is more "nice to have" than super important. And as {Binding} and x:Bind are two completely different things behind the scenes and the runtime stuff with {Binding} is non-trivial like you mentioned, forget about {Binding}. I think having it just for x:Bind is totally fine, it will work for the use cases I can think of. And from all the conference talks I did on UWP and x:Bind, I can tell you that x:Bind is one of the most favorite UWP features of all XAML developers and I told all of them "Prefer x:Bind over Binding wherever you can". :) Getting intellisense, perf, step-into-code, and compile-time errors makes x:Bind the new default on UWP, so having the validation support just there is fine and a good decision imo.

Just INotifyDataErrorInfo and DataAnnotations paradigm? 👍

Just supporting INotifyDataErrorInfo and DataAnnotations paradigm sounds good to me. WPF doesn't pick up Data Annotations automatically, you need to hook them up manually in your INotifyDataErrorInfo implementation by using the Validator class. You mean this when you say "DataAnnotations paradigm", right? Or do you plan built-in DataAnnotation support that allows a dev to just put a Data Annotation on a property and this just works? Like in ASP.NET Core MVC? While that would be great, I think it's not necessary. Having the classes ValidationContext, Validator and ValidationResult and the other classes from System.ComponentModel.DataAnnotations is sufficient imo.

Add Binding.ValidationRules? Noooooo ;-)

No, definitely don't add that. INotifyDataErrorInfo is enough and it's the best. I think I never used ValidationRules anymore after IDataErrorInfo support was added to WPF (If I remember correctly this was in .NET Framework 3.5). And when INotifyDataErrorInfo was added in .NET Framework 4.5, my customers and I have used that interface in all projects for input validation. Supporting just this interface is fine.

Add ValidatesOnNotifyDataErrors? No, but...

Yes, you don't have to add this one. But it has nothing to do with the Binding.ValidationRules. This property is directly related to the INotifyDataErrorInfo interface. On WPF's Binding Markup Extension, ValidatesOnNotifyDataErrors is by default true, which means the {Binding} picks up the implemented INotifyDataErrorInfo validation if the bound object implements that interface. If you set the ValidatesOnNotifyDataErrors property on the Binding markup extension to false, then the Binding Markup Extension won't pick up the INotifyDataErrorInfo implementation for the validation. So, maybe this isn't too hard to implement with x:Bind, but maybe we don't need it. So, no, don't do it. That's ok to leave this out. But let me describe the scenario where I needed this in the past:

WPF controls show by default a red border that is defined via the Validation.ErrorTemplate. Now let's assume you have an INotifyDataErrorInfo implementation with a class that has FirstName property. It's required, so you return an error if the FirstName property is null or empty. Now you bound a TextBox to that FirstName property. When a user removes that firstname, a red border appears. Great, exactly what you want. But maybe you have at another place in the UI another control that is bound to the FirstName property too. For example a TextBlock in a Tab-Header. WPF will display on that TextBlock a red border too when there's a validation error. But this might not be what you want. You want the error just on the TextBox where the user can change the firstname, but not in the TextBlock in the Tab header. To get rid of the red border on the TextBlock, you don't have to edit the TextBlock's ErrorTemplate, instead you just turn of the INotifyDataErrorInfo validation on the TextBlock-FirstName-Binding by setting the ValidatesOnNotifyDataErrors property to false. That's the one and only use case I ever had for this property. :)

I hope this helps.

Summary

Yes, I totally agree, having input validation just on x:Bind with support for INotifyDataErrorInfo is a good plan.

No, it's a fantastic plan, I'm already super excited!

[stevenbrix]

@thomasclaudiushuber thanks for the detailed follow up! The core scenarios you describe lineup with what we believed to be the real value driver, and so that's good to hear. The overall design of this feature and API has been in flux, mostly due to the previous work that WPF had. There were a few major things to call out here:

1. As discussed above, there were certain aspects of WPF's validation system that we didn't feel added any value, or were superseded by better patterns, and so we weren't planning on bringing them to UWP.

2. Certain features/functionality of WPF's validation system take advantages of core WPF features that don't exist in UWP. Most notably here is the adorner layer, which allows any UIElement in WPF to display validation visuals, not just Controls (via adding some template part).

3. UWP Xaml does not currently have the concept of attached events, and mirroring the Validation class would add the Validation.Error event. Not that is a deal breaker, just something to call out as we're generally wary of adding new concepts, as it only adds complexity. On top of that, since the work requires changes to the Control's Template, only the set of controls we provide the specific template changes for would work out of the box. Generally speaking, having an API that appears to work, but doesn't in some scenarios is not good practice, and so we were thinking it would be better to divorce ourselves from that model. This would mean having something else like a common interface and/or attributes that controls implement.

We're still in the process of understanding how to do API and spec reviews in the new and exciting open source world. We'd love to get the community's feedback, so hopefully we can get the API proposals out soon so the community can take a look and help us land something everyone is excited about!

[mdtauk]

@stevenbrix When you do begin the open source spec for the validation features, will you provide the illustrations of how the validation will look, as well as the sample scenarios so the conversation can be a little broader for those of us more into the UI side, than the coding :)

[LucasHaines]

@mdtauk Absolutely. The current UI we shared is still accurate. If you have feedback, feel free to provide on this thread.

[thomasclaudiushuber]

@LucasHaines The UI looks good to me. But I wonder how you can adjust how the errors are displayed. I haven't found anything regarding this and I don't know if you have already something to share in that area. Will there be something similar like the attached Validation.ErrorTemplate property from WPF?

[mrlacey]

Is there a timeline for when a formal spec/proposal will be released for this?
What can I do to help this get into the product sooner?

[knightmeister]

I agree with @mrlacey above... I could really use this now, so I'm happy to help out where I can.

[LucasHaines]

We are working on an open spec and I will let everyone know it's available in the spec repo.

[GeertvanHorrik]

Question: why not support IDataErrorInfo as well? It's supported in .net standard, and it would be weird not to support it? This should not affect performance for the people not using it since it could even be checked at compile time which interface to use for the binding?

[LucasHaines]

We started open spec review for Input Validation in the open spec repo. microsoft/microsoft-ui-xaml-specs#26

[knightmeister]

Hi guys, how are we tracking on this - do we have an ETA?

[BusterIT]

Hello together. I was also wondering about that this basic functionality has not been implemented, yet. After I read the discussion on this thread, I decided to create an own easy solution to provide UI validation which is very similar to Blazor-Form-Validation. It supports x:Bind & DataAnnotations validation attributes and is easy to implement. Including submit button (disabled on invalid model state) and validation of nested objects.

Implementation example:

     
... xmlns:validation="using:WinUIValidation" ...

    <validation:Form Model="{x:Bind Person}" OnValidSubmit="{x:Bind Person.SubmitCommand}">
        <StackPanel HorizontalAlignment="Center" VerticalAlignment="Center" MaxWidth="300">
            
            <!--Adds red border to content-->
            <validation:ValidationFor PropertyName="Name">
                <TextBox Text="{x:Bind Person.Name, Mode=TwoWay, UpdateSourceTrigger=PropertyChanged}" />
            </validation:ValidationFor>
            
            <!--Just shows validation message-->
            <TextBox Text="{x:Bind Person.Address.CityName, Mode=TwoWay, UpdateSourceTrigger=PropertyChanged}" />
            <validation:ValidationFor PropertyName="Address.CityName" />

            <validation:SubmitButton Content="Submit" HorizontalAlignment="Stretch" Margin="0,15,0,0"/>
        </StackPanel>
    </validation:Form>

• no additional code behind is required, just XAML
• no implementation of INotifyDataErrorInfo is required, just INotifyPropertyChanged

You can get the package from nuget: https://www.nuget.org/packages/WinUIValidation
or have a look to repository (including example project) here: https://github.com/BusterIT/WinUIValidation

[sjb-sjb]

Future challenge: in addition to IsValid / validation errors, additional information that needs to be communicated about the model state includes IsDirty (indicating a proposed / unsaved value) and IsBusy (indicating model cannot be accessed currently, e.g. transaction is currently underway). An excellent UI will also display and use these states in one way or another. Is such information to be communicated in a similar manner as INotifyDataErrorInfo, managed by x:Bind and also integrated into the UI elements?

[Balu5a3]

I'm using this validation library with WinUI3 and it is working great.

The only issue is, when I'm using NavigationCacheMode="Enabled" in XAML to cache the data entered.
When I comment <validation:Form Model="{x:Bind pkg}" OnValidSubmit="{x:Bind pkg.SampleCommand}" ...
tags, it Cache working fine. If I uncomment <validation:Form Model="{x:Bind pkg}" OnValidSubmit="{x:Bind pkg.SampleCommand}" it throws exception "no installed components were detected. (0x800F1000) in winui3".

Any help in this is much appreciated.

[BusterIT]

I'm using this validation library with WinUI3 and it is working great.

The only issue is, when I'm using NavigationCacheMode="Enabled" in XAML to cache the data entered. When I comment <validation:Form Model="{x:Bind pkg}" OnValidSubmit="{x:Bind pkg.SampleCommand}" ... tags, it Cache working fine. If I uncomment <validation:Form Model="{x:Bind pkg}" OnValidSubmit="{x:Bind pkg.SampleCommand}" it throws exception "no installed components were detected. (0x800F1000) in winui3".

Any help in this is much appreciated.

@Balu5a3 - Thanks for your feedback. I fixed this issue now.
@thomasclaudiushuber - Maybe one day in distance it´s ready to be used in enterprise solutions, too ;)

[cesarchefinho]

I maded an error validation on winui 3

It uses description property of controls that have it, the mvvm model error property and binding mechanism.

For controls that don't have description property (for example, a checkbox) you can bind error message to another control, like an textblock bellow the validated control.

Also these extensions simplify binding from data annotation of viewmodel and reduces the bloated markup of xaml

Can you look to this implementation?

https://github.com/cesarchefinho/MVVMBindingExtensions

[sude22]

We are at the end of 2022, and still there is no real progress with this issue?
Like other people said before, for LOB apps a simple validation via INotifyDataErrorInfo is a minimum requirement.
Or is WinUI3 only designed to build small example apps?

[omikhailov]

I still think that INotifyDataErrorInfo is not more than a legacy. No other framework puts all errors into one heap the way WPF does.

If someone needs validation, then in #8011 I have given links to my validation library for UWP and WinUI.

[r7dev]

With Visual Studio Lightswitch we had a great data validation framework. They could invite the old architects to participate in this project.
Article about the framework.

[jrovny]

Hi, all. Wanted to follow up on this and see if this still on the roadmap or what the current status is. Thanks!

[thomasclaudiushuber]

Hi @jrovny, yes, it is still on the roadmap. Here on the WinUI roadmap you find a feature table that contains a record called Input validation for data fields. But there's no communication when this experimental feature will be available as a supported feature.

[SoggyBottomBoy]

@thomasclaudiushuber is this still on the roadmap? will it be coming in the next release? I can't find it described in the link which you provided

[ghost1372]

Input validation API added in v.1.5 exp2😁

[sude22]

I can't see it in the ReleaseNotes....

[ghost1372]

I can't see it in the ReleaseNotes....

Many changes are not mentioned
Also there is some new controls like PagerControl

See full changes here
https://omds.xaml.dev/WinAppSDKv1.4_v1.5e2.html

[MartinRobins]

Input validation API added in v.1.5 exp2😁

I cannot see anything that indicates how to use this API; are there any examples?

[ghost1372]

Input validation API added in v.1.5 exp2😁

I cannot see anything that indicates how to use this API; are there any examples?

i did not test, but you can try winui 2 examples, mybe you need to changes somethings...
https://github.com/microsoft/WinUI-Gallery/blob/winui2/WinUIGallery/ControlPages/InputValidationPage.xaml

[MartinRobins]

Input validation API added in v.1.5 exp2😁

I cannot see anything that indicates how to use this API; are there any examples?

i did not test, but you can try winui 2 examples, mybe you need to changes somethings... https://github.com/microsoft/WinUI-Gallery/blob/winui2/WinUIGallery/ControlPages/InputValidationPage.xaml

Gave it a try, cannot seem to get anything out of it.
Also, example page seems to be generating error messages in the page code rather than just relying on INotifyDataErrorInfo?

[thomasclaudiushuber]

Hey everyone, the InputValidationPage.xaml file in the GalleryApp is an old thing. If you do a git blame on it, you'll see that it has been around since 2018, and last changes were made in 2020 (4 years ago).

Here's the blame on the file: https://github.com/microsoft/WinUI-Gallery/blame/main/WinUIGallery/ControlPages/InputValidationPage.xaml

So, it might not be an up-to-date version of the implementation that we might see in the future. :)

Let's keep an eye on input validation. If I'll find something out how it works, you can be sure that I'll follow up with all of you here.

[MartinRobins]

Given that this was in the experimental build(s), does anybody know if it is also in the pre-release build?
(even though I still cannot work out how to use it in the experimental)

[ghost1372]

Given that this was in the experimental build(s), does anybody know if it is also in the pre-release build? (even though I still cannot work out how to use it in the experimental)

i checked preview1 and Currently not available it seems that preview1 contains exp1 stuff, so we should wait for preview2 or stable release

[SoggyBottomBoy]

This doesn't appear to be part of the road map for 1.6. Is this true? I'm surprised this is not one of the most requested features. Can anyone provide an update on this?

[cesarchefinho]

No one more needs inputvalidation and no one more need winui3

Avalonia has inotifydataerrorinfo implemented and it works!

Also avalonia has an xaml designer and it works!

Also avalonia works with visual studio, visual studio code and with jet brains rider (especialy on mac)

Also avalonia compiles to windows, macos, linux, androi, ios, tizen and even to browser!

Winui is dead. Maui is dead at born... long live to avalonia.

[thomasclaudiushuber]

Hi everyone,

I added this issue as a suggestion to the plans for Windows App SDK 1.7:
microsoft/WindowsAppSDK#4710 (comment)

If you think it's important, please upvote the comment there.

Thank you,
Thomas