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?