views:

93

answers:

1

OK, so maybe I am really missing something here, but how is it so difficult to do effective server & client side validation in MVC (2)? Here are a few examples:

  1. I want to use a variable length list. I follow a great tutorial like Steve Sanderson's variable length list overview. I want to create a custom validator like "RequiredIf". My variable length list is a collection (using Sanderson's HTML helper for collections), and the custom validators don't fire even with the correct client validation script(s) in-place (that work fine for non-variable length lists)... isn't a variable length list that needs to post back as an enumerable collection to the [HttpPost] action pretty common? Why is this validation so painful on the client side--when you wish to derive from the validation annotation that was associated with your class? In this case, server-side validation actually works... but client-side seems to be impossible when using a collection and a variable-length list. Sure this could be something to do with the HTML element ID naming from the index-Guids of the collection, but it starts to get so convoluted...

  2. I have a ViewModel that may be filled with different types of data. I want to validate in some cases, but not in others. Typically I am filling my ViewModel from a domain class that already has data annotations for validation. However, the ViewModel would need its own data annotations to perform validation correctly. For some fields I want validation, but for other uses of the same field--when filled with different data--I don't want validation. I cannot reference a dynamic property in my data validation annotation though... annotations are static. This must be based on when they bind, etc. Sure I can make a custom validator that gets REALLY crazy and actually references the literal values of other fields in its attempt to decide whether to validate (drawing in booleans for "required", and strings for "regex" or "errormessages")... but ouch! Seriously, is it this hard?!

What is frustrating is that the more I try to follow the patterns provided by MVC, I keep stumbling into things that COULD be so darn simple but get so painful when you can't deviate from the pattern. If data validation annotation is the correct approach, it really seems like it needs to support dynamically set properties and have a better auto-rendering of client JS (specifically for custom validators) to avoid these headaches. I'm almost done trying to make client-side validation work in these situations.

Has anyone used a validation package that makes this process easier? I am not familiar enough with the support for the MVC 2 compatible validation packages to know whether they're worthwhile. I've skimmed Fluent Validation for example, but need to learn more. Does it allow dynamic validation assignment and client valdiation for custom validators?

One idea I am considering is simply adding data fields in my domain model that provide a view-usable string which a package like JQuery validation can pick-up and use to avoid this entire situation mentioned above. That way my domain model can use annotations to protect its data integrity (and will serve as a last-stop for any insert issue), and my client side can just have a string to throw into a class attribute for a scripted validator to use without having to go through the craziness of exposing custom validators on the client-side with a bunch of overkill/interpretation of "IEnumerable GetClientValidationRules()..."

What gives? Is there a better way?

A: 

You always attach/remove attributes at runtime:

http://stackoverflow.com/questions/3607247/dataannotations-dynamically-attaching-attributes/3609521#3609521

jfar
This doesn't cover the client-side validation issues at all though. I will review it... MVC 3 may have some promise, http://weblogs.asp.net/scottgu/archive/2010/07/27/introducing-asp-net-mvc-3-preview-1.aspx -- has anyone tried this?
Jon J