UWP Input Validation
As an enterprise developer we need a richer set of Line of Business features. Input validation is fundamental to business applications and should not require us to roll our own or find a 3rd party solution.
With the announcement and preview release of WinUI Nuget package, we are able to release and update XAML controls independent of OS Updates. We also design controls for backwards compatibility. We’ve listened to customer feedback based on our initial implementation, one being to enable backwards compatibility. Due to this feedback, we are adjusting the implementation to include Input Validation inside the WinUI Nuget Package. We are hopeful to release a backwards compatible version of Input Validation in calendar year 2019.
Thomas Claudius Huber commented
Looking forward to it. Releasing this as a backwards compatible version is great and really important for enterprises. Especially enterprises usually don't switch to the latest Windows 10 version immediately after it was released.
Thanks for the update Clint.
Thanks for the update. I'm just an observer for now, but I'd love to start programming with UWP-XAML one day. I keep googling UWP in conjunction with other important keywords like INotifyDataErrorInfo, OutlookBar, Ribbon, AdornerLayer, DataGrid, etc. My searches typically turn up nothing month after month (although there is now a datagrid!) . These are the types of things that seem critical for normal line-of-business desktop applications.
Lately I've been wondering if Microsoft decided to add adornerlayers into UWP to support input validation. Maybe that is what is taking so long (and if so it would be well worth the wait). I suppose we'll have to wait and see...
I'm looking forward to seeing your new input validation in WinUI. I believe those nuget packages need to come out of preview too, while you are at it.
Thanks for the ETA. Keep up the good work.
Any word on this? It would be great to see an estimated ETA as well. INotifyDataErrorInfo is something that would be very handy, and a UWP developer shouldn't be reinventing it for themselves.
As a side, it sure would be nice if the UWP/XAML framework could move along faster than it is. It is no wonder that enterprises are scared to start building line-of-business applications, considering that even Microsoft take years to add user interface components. Another example is the UWP datagrid in the windows community toolkit. That has finally become a reality in this year in August but many developers were already waiting on it back in 2011 when WinRT XAML was introduced at BUILD.
Thanks Harini! Glad to hear this because I know that you're trying to make XAML as standard as possible across the board so hopefully the solution will use INotifyDataErrorInfo like the other platforms.
Thomas Claudius Huber commented
Are there any news around this idea?
@Jerry Nixon: I think INotifyDataErrorInfo gives you at least a way to support what many developers are using today with WPF. But yes, we shouldn't think in boxes. :) Your approach is a ViewModel for a property, that's a great approach. I used it already in the early times of WPF. Look here at the diagram of this article I wrote in 2007! on page five: https://www.thomasclaudiushuber.com/articleresources/200710_ModelViewViewModelArticle.pdf It shows a ViewModel for strings and also for datetimes. It's the same idea you have in mind, but you have a generic base class for your properties, which is a great idea.
When building WPF projects, I found that the PropertyViewModel approach sometimes has the lack of loosing the connection to the real model/object. Instead of digging deeper and trying to solve this, I thought it would be better to wrap the whole object instead of separate properties. And this is what I did in the past years in WPF. I've described everything in a Pluralsight course that is available here: https://www.pluralsight.com/courses/wpf-mvvm-advanced-model-treatment
I like your idea. But I think the framework should provide something flexible that allows different ways. Then we could still build something like you've posted on top of the input validation base provided by UWP. What do you think?
Jerry Nixon commented
I believe that INotifyDataInfo is simply too limiting. Here's a prototype of what I believe we really need: https://github.com/Windows-XAML/Template10.Validation/blob/master/Library/Validation/Property.cs
This item is too broad. Specifically, Microsoft needs to implement functionality on UWP controls so that when an object is bound to a control, and that object implements INotifyDataErrorInfo, the control should listen to error changes, and display them accordingly. This is excellent functionality in Silverlight and WPF.
Danny Hooser commented
+1 @Karl. Please make this happen. All LOB applications I write heavily rely on this feature in WPF/Silverlight. This is a major blocking issue to move forward with UWP for our company.
Anthony Johnston commented
I have been struggling with this too, not a fan of data annotations.
Came up with this as a starter for 10 https://gist.github.com/MrAntix/f1fad919e06fc812e374c07c70a748ec
even works with x:Bind :)
Template 10 (and Prism before it) is great as a demonstration of some key concepts. We have Validator, IValidatable, and validation attributes in uwp.
What is missing is MS resources and development to make a complete, well designed and supported View Model and validation layer that is on a par with EF itself.
It seems like they are okay with 3rd parties filling this role. During yesterdays win10 creative update webinar they had a rep from telerik speaking about all their enterpise features(datagrid/form validation) for uwp. I have been using syncfusion's datagrid with some success but I find 1st party controls have more polish and are better tested.
Has there been any progress on this? I am somewhat baffled by the fact that we had Prism as an official Microsoft framework, and it was quite capable. Then when Sinofsky started running the show, Prism fell off the futures road map. It eventually came back and was subsequently released into the wild as an open source initiative no longer officially supported by Microsoft.
Template 10 is yet another framework that does not have direct support from Microsoft despite Nixon's fine efforts and close ties to Microsoft. What's most baffling about all of this is the fact that WPF/Silverlight key LOB capabilities have been lost with the move to UWP.
Only as of November 2016 did we get back a usable Entity Framework implementation for UWP that will not be backward compatible! The new features and roadmap is great, but core capabilities for LOB use are only just starting to appear. There is no UWP Data Grid control for LOB. I've heard several reasons for why this is so (from a curious Microsoft design perspective), yet Microsoft was able to incorporate this for its Excel UWP app?
LOB needs validation, a fully formed EF, and a DataGrid. EF is almost there. Please address the other two real soon.
Prism doesn't work well in uwp because x:Bind doesn't allow string indexers.
Thanks anonymous, I will check it out. Jerry Nixon is doing good work on template 10.
Use the excellent Template10 Validation library:
Brian / Karl, why i didn't close this out :) Just gave a possible framework to unblock.
Karl, shoot me an email (email@example.com) and lets see if we cant do something.
I have looked at the prism documentation on input validation and it would work but I think most of us are looking for an implementation similar to the wpf/silverlight methods.
Karl Shifflett commented
Prism for UWP needs to be rewritten. Brian Lagunas and I have talked about it.
The point is, there is a big hole in the UWP Xamarin Forms Data Binding stack.
XAML is Data Binding. Without a good data binding story, other technologies are better choices for LOB and Enterprise. Probably not something you or Microsoft would be in favor of. But I look at Enterprise adoption and its low. If you fix this, the platform will be much more attractive to developers for LOB and Enterprise, that's desktop, table, phone, etc.
I look at this hole as a platform adoption blocker for LOB and Enterprise.
Without this, we have to write our own framework to get around this.
Data validation is critical to any LOB or Enterprise app. We can be writing code-behind validation like demo-ware does.
I'm not sure the folks that wrote the data binding stack in 2013-204 for WinRT appreciated the rich data binding stacks of WPF and Silverlight 4-5.
As a customer, I fully expected a better stack, not a lesser one that didn't meet my current desktop needs. Heck, ever Windows Phone 7 had IDataErrorInfo.
I noticed that the data binding team enabled developers to add C# code inline within XAML to eliminate the Converter.
Not sure how that got prioritized above this. Putting C# code in XAML, break separation of concerns, probably can't be included in code refactoring, and is an Edge Case Scenario at best. Honestly, I would never do it.
Sorry for the long winded reply, but we need this.
Appreciate your attention and championing getting this in.
I'll be in Redmond 8-10 Sept, would love to meet with you and the data binding team.
Build 1607 (Anniversary update) added the ability to install appx apps without the store so it sounds like they are listening to us (enterprise app developers) it would be nice to see a road map.
Microsoft this is CRITICAL for LOB and enterprise apps.
This is a large hole in the binding stack. Developers need this now.
I just can't understand the thinking at Microsoft, this is a BLOCKING use.
Please don't do the same thing the Silverlight team did to developers, which was inching the API's along over a period of YEARS.
Please bring the UPW binding stack to parity with WPF.