EmailAddress and DataAnnotations

Apr 16, 2009 at 11:33 AM
Woh, EmailAddress isn't supported..prolly a few other DataAnnotations that aren't mapped either. i'll create patches as I hit them

Here's my patch... can u let me know when/if it goes in Steve so I can build from trunk.

... hmm, this patch is coming soon..gimme a few mins


Coordinator
Apr 16, 2009 at 12:05 PM
CVertex, I'm not sure what you mean by this. DataAnnotations identifies email addresses as follows:

[DataType(DataType.EmailAddress)]

... and xVal's DataAnnotationsRuleProvider certainly does support that. The jQuery.Validator and ASP.NET native client-side libraries also know how to support the resulting rule.

Can you provide an example of what you're saying isn't supported?
Apr 16, 2009 at 12:25 PM
Sorry Steve, i only just got the xVal unit tests running with R# so I could debug and understand xVal via the unit tests.

I only just noticed the difference between DataTypeRule and RegularExpressionRule. It appears the RegularExpression rule is validated on the server side. I also just noticed that DataTypeAttribute maps to DataType Rules.

xVal may or may not be written to help me here in this case.

so I have a business tier object like

class Invitation {
[Required]  
[DataType(DataType.EmailAddress)]
   public string Email{get;set;}

   [Required]
[RegularExpression("^[a-zA-Z]+( [a-zA-Z]+)+$", ErrorMessage = "We need first and last name")]
   public string Name{get;set;}
}

In my controller action, I run the DataAnnotationsValidationRunner.GetErrors(invitation) from your blog post. The runner errors on the regular expression rule, but not the DataTypeRule.

I realize xVal isn't exclusively designed for server side val, but it would be nice to catch these errors on the server for clients that call my site from an JSON API style Controller interface.

Should I just change Email attribute above to a RegExpAttr?
or do you think it's in scope for xVal to provide a runner + DataType validator for DataAnnotations like it does for RegularExpressionRules?

Regards,
CV




I know this is a misconception
Coordinator
Apr 16, 2009 at 1:28 PM
Edited Apr 16, 2009 at 1:29 PM
OK, now I understand!

When I originally put DataAnnotationsValidationRunner on my blog, I didn't expect people to think that it was part of xVal. However, quite a lot of people have done, and then have been confused about what's in scope for xVal and what isn't. The server-side runner isn't supposed to be part of xVal at all, because xVal is about transferring server-side rules to a client-side validation framework.

I'm aware that DataAnnotationsValidationRunner from my blog doesn't validate email addresses on the server (which is because for some reason System.ComponentModel.DataAnnotations itself doesn't, even though it does correctly validate [Required] and the other rules). However, xVal does respect *all* the rules (including ones about email addresses) for the purpose of client-side validation.

I would suggest that you take DataAnnotationsValidationRunner from my blog as a starting point for implementing your own complete server-side DataAnnotation runner. I guess we could consider making xVal actually *do* the server-side validation in future (instead of merely assisting server-side validation, as it does now) but I was hoping to leave that open to give users more flexibility.
May 19, 2009 at 10:28 PM

Having xVal actually do the server-side validation would be a wonderful bonus;  either that, or a supported/provided DataAnnotationsValidationRunner that handles the validation cases/attributes that System.ComponentModel.DataAnnotations doesn't! 

I'd love to be able to implement my own as you suggest, but there is still so much to learn (am loving your book, by the way!) before I think that will be possible.  I've looked at several other packages and have read countless blog posts in an effort to find a single, comprehensive, and elegant  solution to my validation needs, but I don't think I've found it quite yet. Rolling my own seems to be the solution but not something I think I'm ready for just yet.

Thanks!