This project is read-only.

Validating data

May 1, 2013 at 5:50 AM

I am adding some validations to the code. My approach is:
  • In the implementation class on the host side I have a save method.
  • In the host save method, I first call a validation method that returns a string.
  • If the string is empty, I find the record in the entity, update (or add) it, and then call the context.SaveChanges.
  • If a string is returned, it contains an XML list of all the items that failed (with a field enum to let me know which field corresponds to the error). I then set the response.success to false and the response.FailureINformation to the xml string.
  • On the client side, I can then parse the xml string and show the user all the errors or things that need to be fixed.
  • Is this an appropriate approach or is there a better/more effective/more efficient/etc. approach to handling this?
Also - how much validation do you do on the client side (for example, those items where the UI has to react to what the user has entered.) And where is the best place to put that code (the controller, model, or view (I assume the model.)

And, if the UI does need to be updated based on the data entered so far, how do we do that while still allowing someone to use blend (or another WPF tool) to manage the UI? For example, if the user checks a box that says they own a house, we may want a page to become visible/available that allows them to enter information about the house. I would assume we would create a command in the model that would be tied to the checkbox click - but then, how would it tell the view to update without having code in the UI (especially the xaml)?

May 1, 2013 at 7:05 AM
BTW, if there is a tip or CODE mag article on this, just point me to that - it's late and I may have missed it.

May 1, 2013 at 9:00 AM
The services are always the gatekeepers and therefore must be the custodians and enforcers of all the business rules. The "trust no incoming data" rule applies here.

The approach you take is workable. Again, I am not thrilled about expressing anything as XML low level these days since you can do everything with objects you can do with XML, and using objects has other benefits (such as turning them into JSON or other formats that may be useful either in the future or other current scenarios). But conceptually, what you describe works.

On the client side, I often add additional logic and rules. Enabling and disabling UI elements based on business rules. Forcing the user to enter required fields. That sort of stuff. It results in a better user experience if you do that on the client in addition to the server. (But you still need to make sure you validate rules such as required fields on the server).

As for the logic you describe: If a user checks a box that says they own a house, then I would bind that to a property in the view model. In the setter of that property, I would check if the new value is true/checked, and if so, I would trigger async loading of whatever data is needed to be retrieved (if any) and then I would have another property that handles visibility.

Consider this view model example:
public class MyViewModel : ViewModel
    private bool _hasHouse
    public bool HasHouse
        get { return _hasHouse; }
            _hasHouse = value;

    public Visibility HouseInfoVisible
        get { return _hasHouse ? Visibility.Visible : Visibility.Collapsed; }
You can then have objects in XAML like these:
<Checkbox Checked="{Binding HasHouse}" Content="I have a house" />
<Grid Visibility="{Binding HouseInfoVisible, Mode=OneWay}">
    <!-- Edit controls for the house details go here -->
May 1, 2013 at 9:05 AM
Note: That example assumes it doesn't need to load any additional data. Otherwise, you would trigger an async load after the first NotifyChange.

May 1, 2013 at 5:03 PM

The idea of xml was so that I could use the response.FailureInformation string to return a list of errors (vs. 1 at a time and require the user to click save to get the next error.) I guess I could add a List<errorObjects> to the response object which would work the same and be easier to parse. Thanks for the tip.

That solved, is there an easy way to search for the control in the FE that is bound to a given field? And to identify the label that is associated with that field?

I would think that in some cases (the simple edit where the UI simply has label/field pairs) it should be straightforward. But if I have to layout the controls to match some requirement, is there a property I can use to identify the label associated with a field?

In my case, a requirement is that, if a field value is invalid, I have to change the color of the label to one color and if the field is required, I change it to a different color. So I need an easy way to find both the label and control programmatically in these cases.


May 2, 2013 at 9:48 PM
Well, with that said, I would not use FailureInformation for it and stuff XML in it. FailureInformaiton is meant to be a simple text field that aids in searching what the real problem is, nothing more. For your purposes, a collection of broken rules would probably be better.

There is no built-in way to find the bound control. Not something you should do anyway ;-) since you'd now be tightly coupled to that control. Instead, in WPF you can use the error provider feature to automatically highlight a control when it is bound to a problematic field.

May 3, 2013 at 3:26 AM

Thanks, but when I tried to find references to the WPF error provider, all I kept finding were peoples solutions to implement one when they found that early versions of WPF didn't have it.

I am sure the information is out there, just a little difficult to find. Any pointers to information on how to implement it would be cool (and information that might apply to a CODE FW based views).

it's so frustrating going from an environment like winforms (which, while flawed, made lots of sense to me) and jumping into this whole wpf world. I know I will get the hang of it, but it's frustrating trying to figure it out - especially when WPF has changed quite a bit and a lot of the info I find out there is now quite out of date....


May 3, 2013 at 6:45 AM
Yeah, it isn't as simple as it should be in WPF. You can take a look at an article like this one:

Not the newest one though. Just something I found after a quick search.

I've had it on my list for a while to add some built in error functionality like that. Maybe I can bump it up in priorities a bit.

May 13, 2013 at 6:56 PM

I have looked at it the link (and related topics) and just need to get some idea of your plans (i.e. yes/no and some idea as to when) to implement it. Otherwise, I will end up having to implement it (and most likely will not do it the way the fw will....). My guess is that we would update the styles to have support and then have some standard approach to adding the validation.

The other issue is if some of the validation can be done on the client vs. roundtripping the data for every little validation (although I would assume that a fair amount would be done on the Backend just so we don't have much duplicate code.)

I would assume we could have some controls that subclass and can have some basic validation built in (states, zipcodes, dates) as well as maybe add support for attached properties for some basic concepts (can't be blank, ranges, etc.) But I am not sure if this will be as easy as I make it sound (or was in winforms). Then we just set the appropriate property when we need the basic validation.

Also, even if you don't plan to add support for it now, it might be nice to at least define the structure of the list of return error messages so that, should it be added at a later time, we don't have to re-write all the notification code.


May 16, 2013 at 11:20 PM
It's one of those things. I really want to do it, and all it would take is a few days of uninterrupted time. I am hoping to get it into one of the next builds. But then there are so many things our customers need urgently that always bubble to the top faster. So I guess what I am saying is that I am not entirely sure how quickly we can get that in...

Aug 20, 2013 at 10:36 PM

I am looking at implementing the client side UI validations - things that need to happen when a user does something.

I have a few approaches I can use.

1) I can use the IDataErrorInfo, INotifyPropertyChanged type approach.
2) I can create a series of ValidationRule based rules that I can reference via the XAML
3) I can put code to do things in the various get/set methods (I like this the least.)

I like the article that Paul Stovell wrote about IDataErrorInfo and INotifyPropertyChanged - - from the standpoint of having an array of rules that included the property and validation criteria as well as having it work without interrupting the user unless the user tries to save.

Anyway, I am playing with these, trying to figure out which approach might be the best one. But I wanted to check with you to see if you have finalized your plans for the approach you want to use with the CODE FW. If so, then I can use a similar approach and marry the 2 together when the support is added to the CODE FW.


Jun 1, 2015 at 4:40 AM
Markus, what ever happened to adding some built-in error functionality?
Jun 3, 2015 at 4:51 AM
Weeeellll... good question :-)

It is still on the to-do list, but it just hasn't bubbled to the top yet, since people throw so many high-priority items at us.