Validation Easter Egg

When asked to list some really cool, "selling" features of ASP.NET one of the first things that come to mind are validation controls. I am a huge believer in validating everything a user enters. At my previous job we had a monster web app developed in "classic" ASP, and about 50% of all bugs were related to invalid data that was never validated in the first place.

ASP.NET validator controls ease this pain immensely. You can force the user to fill out a required field, you can run all kinds of comparisons against entered values, you can display a summary of data entry errors, etc. One of my favorite ones is the regular expression validator control.

Validators have a peculiar and somewhat confusing property: Display. Inherited from BaseValidator, it indicates whether the error message is pre-allocated on the page (Static) thus taking up some space, or is added dynamically (Dynamic) if validation fails.

Dino Esposito goes a bit further in his book Programming Microsoft ASP.NET (page 156). When Display=Static (which is so by default) the validator renders as

<span style="color:Red;visibility:hidden;" ...>

The box, generated for the error message, is invisible (fully transparent), but still affects layout. When Display=Dynamic the same tag is rendered as follows:

<span style="color:Red;display:none;" ...>

In this case the CSS display property causes an element to generate no boxes in the formatting structure. A validator will only take up space if its error message is displayed.

The third possible setup, Display=None, causes a validator to display nothing, but put its errors (if any) into the validation summary.

All this applies to client-side validation. In case of server-side validation the Display property is ignored altogether, however what validator controls output is quite peculiar. In his MSDN article, ASP.NET Validation in Depth, Anthony Moore says:

For server-side validation, Display=Dynamic means that nothing at all displays when the input is valid, while Display=Static means that a single nonbreaking space ("&nbsp") is emitted. This last behavior exists so that table cells containing only validators do not collapse to nothing when valid.

This is where you slam the brakes. This is also the first time I see this explanation. Was there made an architectural decision on an assumption that someone puts a bunch of validators in a table cell which may collapse? To me, this is an architectural Easter egg.

Where Are Validators On An Evolution Chart?

I think validation controls are about 80% where they are supposed to be. First, I'd like to see no such assumptions applied to their development because it will only get us in trouble. Second, I hope validators produce clean, well-structured markup. As I alluded in my post Serving XML: Le Divorce the validation summary control doesn't live up to this wish. If you are of a brave kind and ventured to serve your content as application/xhtml+xml and use validation summaries you have a recipe for disaster.

Other that than, validators are the second best thing after sliced bread! Happy coding, and remember:

All user input is evil until proven innocent!

Validators are great, but the out of the box validators don't work with non-IE browsers. You either have to reinvent the wheel yourself, or step up to a third-party product like Peter Blum's VAM controls.

You had mentioned you think the validation controls are about 80% there but I'd say they are more like 40% there. I'm getting no money to say this but if you check out the Peter Blum validation you'll see how far MS has to go. We started using it at my company and it really does a good job of filling in the gaps.