[Feature] The new MVVM-Library should allow to run validation manually

[timunie]

Describe the problem this feature would solve

I tried the new MVVM Library and it suits my needs very well. I used the ObservableValidator to send messages to the user if something is wrong or missing. Unfortunately the validation will only apply if the value is set and actually changed. There might be usecases where the value did not change but needs to be validated again anyway.

Example: You have a number a=10 that may not exceed another number b=5. If now b changes to b=20 a=10 is now valid but will not be validated because it did not change.

Another example if if you want to validate the class right after creation and want to mark properties that still hold the default value of null

Describe the solution

The user can call ValidateProperty(string PropertyName) to validate a property or ValidateAll() to validate the entire class.

Describe alternatives you've considered

Set the value to something different and restore the old value then. But IMO this is not a good practise.

Additional context & Screenshots

The class on startup - It is not validated as the values were null at start up

The same view after typing a letter and reset it to null again. I want this view on start up

[ghost]

Hello, 'timunie! Thanks for submitting a new feature request. I've automatically added a vote 👍 reaction to help get things started. Other community members can vote to help us prioritize this feature in the future!

[Kyaa-dost]

Looping in @Sergio0694 to provide insight on this and see if this is suitable for the library.

[michael-hawker]

Thanks for the info @timunie. I know there's been some discussions on validation after we shipped the last preview I believe. It's good to get some background on the scenario you're trying to accomplish here.

@Sergio0694 have any changes been made since or does this help to provide background on any changes we should make before shipping?

[Sergio0694]

@timunie Thank you for the suggestion! I agree that those two scenarios would be helpful, we're looking into that 😄

@michael-hawker What I've added recently were those new TrySetProperty methods that were requested, but those mentioned in this post are not available currently. The main reason was that the two suggested APIs would've required using reflection, which we were trying to avoid, and that we weren't sure yet on what approach WinUI was taking for supporting the interface, so I was waiting for more info on that front to align the available APIs in this class to fully support that out of the box too.

That said, if we decide it's fine to offer these two APIs since the initial version, and to have these two be backed by reflection to work, I can certainly try working on a draft implementation for them so we can continue the conversation about this 😊

[timunie]

Hi @Sergio0694 and @michael-hawker

I am very impressed by this fast answers. 👍

I created a short testing app to show the issue and test improvements. Basically it show the scenarios explained above. https://github.com/timunie/MvvmToolkitValidationSample

If there is anything else I can do to support you feel free to ping me.

Happy coding
Tim

[timunie]

Would you mind if I take your current implementation and modify it to my needs? It would be available in my own library and will be removed when this package is stable and released.

If I should not make it open source I can also just use it privately.

[Sergio0694]

The package is MIT licensed, so you certainly can fork the library and customize it to fit your needs, even more so if you only plan to use that privately. If making these changes will unblock you for now before they're eventually shipped officially, then sure, that's a perfectly valid approach to take 😄

I'll experiment with these suggested changes on my end too and will see if I can integrate them in #3428 🙂

[timunie]

Faster support than I am used to for paid programs. Incredible.

I have my changes here:

• https://github.com/timunie/TimsWpfControls/blob/6b6410617f3da826948d8c0210c62dcaf1897e9b/TimsWpfControls/TimsWpfControls/Model/BaseClass.cs#L670
• https://github.com/timunie/TimsWpfControls/blob/6b6410617f3da826948d8c0210c62dcaf1897e9b/TimsWpfControls/TimsWpfControls/Model/BaseClass.cs#L621-L655

It basically just adds the following methods AutoValidateProperty and AddError and ClearErrors. The two last methods are from the old baseclass. I did not remove them for compatibility reasons for now but I would not need them in the future.

If I should send you a PR let me know.

Happy coding
Tim

[Sergio0694]

Well I guess we can discuss other APIs to introduce and how (in particular, one to validate everything), but for starters, making ValidateProperty no longer just private, but protected like the other exposed APIs, seems perfectly reasonable and does solve the issue with "dependent validation" mentioned in this issue. I've made the change in 207dc98 and added a unit test with a similar scenario to the one described here, and linked this issue there for future reference as well 🙂

[timunie]

Hi @Sergio0694 I tested your changes in my own library and can confirm that this would be a solution for my use case. I am really looking forward to the release.

Thank you and have a great weekend 🙏
Tim

[Sergio0694]

Glad I could help, and thank you for the valuable feedbacks! 😄