Home     About PeterBlum.com     Policies     Download a Licensed Product     Newsletter
Addressing 30 Limitations of Microsoft's Validation Framework Try It   Buy It


Over the first year of using Microsoft ASP.NET, I implemented around 10 new validator controls based on the System.Web.UI.WebControls.BaseValidator class. As users of these validators provided feedback, I identified a number of limitations in the Microsoft design. They come from these key design choices:
  • BaseValidator is subclassed from System.Web.UI.WebControls.Label. That defines a single UI approach.
  • There are no separate objects for concepts like the evaluation condition or data types. This prevents code reuse. For example, if you want to implement a Time Of Day data type, you have to create new versions of each of the Microsoft validators (Range and Compare).
  • The client-side code is heavily imbedded into the BaseValidator, Page, and Button objects, preventing client-side enhancements like support for new data types or changing the color of the field with the error.
Peter's Professional Validation introduces a new data entry validation framework. It abandons all the client and server-side validation code written by Microsoft to provide an object oriented structure that resolves its limitations, is greatly expandable, and provides much more functionality. If you are already familiar with Microsoft's Validation controls, these new controls are set up in much the same way, with many new properties and a few differences in the names of properties and classes.

What are the limitations within Microsoft’s validation framework and how does this product solve them?

Problem

You need more validation rules than are included within the four predefined validator controls: RequiredFieldValidator, RangeValidator, CompareValidator, and RegularExpressionValidator. You frequently have to code your own validators and learn JavaScript with the CustomValidator to get the rules you need.

Solution

Peter's Professional Validation includes 24 Validator controls, each with a unique "condition", two custom validators for creating your own and the powerful MultiConditionValidator. Click here for a list.
They still support all controls that use the ValidationPropertyAttribute, plus new field types like CheckBoxes and RadioButtonLists and even third party controls.

Problem

There are times when your validator should not run. For example, if you have a RequiredFieldValidator on a TextBox and only consider that TextBox active when a nearby checkbox is marked, you want the RequiredFieldValidator to be disabled while the checkbox is unmarked. While Microsoft's validators have an Enabled property, you have to write complex javascript to switch it on the client-side.

Solution

Each validator has an Enabler Condition. This allows the validator to turn itself on and off automatically based on any condition you want. When off, the validator will not attempt to evaluate the fields. For example, you have a TextBox whose RequiredTextValidator should only validate when a checkbox is marked.

Often you will want to disable the validator when the data entry field being evaluated is invisible, disabled, readonly or have some other attribute. DES supplies these specialized conditions for use in the Enabler Condition: VisibleCondition, EnabledCondition, ReadOnlyCondition, ClassNameCondition, and CompareToValueCondition. This last condition can evaluate almost any DHTML/DOM attribute or style on the data entry field.

The Enabler Condition can use the powerful MultiCondition (the condition from the MultiConditionValidator) to build complex boolean expressions such as: "enable this validator when the TextBox is visible AND enabled AND the CheckBox1 is checked".

Problem

When multiple textboxes are evaluated by the same validator, sometimes you want to delay validation until all fields have been filled in.

Solution

Peter's Professional Validators that handle multiple data entry controls offer the ReportErrorsAfter property to determine if the validator should wait until the user has moved through all of those controls before validating.


Problem

There are times you want to report a problem to the user, yet its not severe enough to require an edit. The user needs a kind of warning or notice.

Solution

When it's EventsThatValidate is set to OnChange, the validator effectively becomes a warning message as it doesn't prevent the page from being validated. DES will optionally show a confirmation message when the user submits, listing the warnings, to get permission to continue.

Problem

Many times, a rule for validation really needs to be built from multiple conditions and fields. For example, you want to combine the RequiredFieldValidator with the CompareValidator.

Solution

Peter's Professional Validation includes the MultiConditionValidator to build Boolean expressions from Condition objects. This single Validator often replaces the need for the CustomValidator.

Underlying the MultiConditionValidator is the powerful MultiCondition object that you can use in the Enabler property to handle more complex situations like "only enable this validator when the TextBox is visible AND enabled AND the CheckBox1 is checked"

Problem

Many users prefer to blend several validators into one error message.

Solution

The MultiConditionValidator allows you to have one error message representing several other validators. For example, one message appears when either the RequiredTextCondition or DataTypeCheckCondition report an error.

Problem

A single validator, button, or the ValidationSummary control needs to handle multiple Validation Groups. For example, a textbox is shared by two ValidationGroups so its validators need to work with both groups.

Solution

ValidationGroups let you mark each validator and submit button with a group name. The submit button will only validate those members of its own group. Peter's Professional Validation allows you to assign multiple validation groups to a validator, the ValidationSummary control and its buttons.

Problem

If you want to customize the format of the error message, such as show an image, you have to embed HTML into the ErrorMessage property. This causes several problems.
  • HTML in the error message may not be right for the ValidationSummary, requiring you to write another error message with the same text but without the HTML just for the summary.
  • HTML appears as tags in an alert box generated by Microsoft's ValidationSummary control's ShowMessageBox property.
  • If you decide to change the formatting, you have to edit all ErrorMessage properties.
  • Requires more complex formatting that includes JavaScript or tables may be too difficult to manage within the error message itself.
Solution

Peter's Professional Validation separates the error messages from error formatting. It uses ErrorFormatter objects to translate the error message into its on-screen appearance. You can easily switch between ErrorFormatter objects without editing the error message. ErrorFormatters can be assigned default values in a configuration file so that you can define their appearance globally. Peter's Data Entry Suite supplies the following five Error Formatters:
  • Text – Like the Label webcontrol where you see the text with the styles of your choosing. You can supply an image that appears before the text and properties to put any HTML you like before and after the error message.
  • Popup - Uses a PopupView, which is similar to a tooltip or balloon, to display the error. The user can either point to the image shown when an error occurs or the data entry control itself to display the PopupView.
  • Image with tool tip – Only show an image. Images can use much less space on the page and will always use the same amount of space when used on multiple validators. When the user points to the image, a tool tip exposes the error message.
  • Image with Alert – Only show an image. When the user clicks on the image, an alert shows the error message. The image has an optional tool tip to tell the user to "click for more details".
  • Hyperlink with Alert - Show a hyperlink with a static message like "Error". When clicked, an alert shows the error message.
You can create your own ErrorFormatter classes as well.

Problem

Some users prefer to show a graphic next to fields that have been corrected.

Solution

DES provides the NoErrorFormatter property on each validator. Use it to establish the appearance and a rule when to show the graphic.

Problem

The error message shown on the page is the only way to communicate the error when the field is changed.

Solution

In addition to showing the error message, Peter's Professional Validation provides several ways to get the users attention and assist them in responding to an error:
  • Put the focus on the field with the error.
  • Change the style of the field with the error. For example, change the background to red.
  • Change the style of the field's label, container, or other fields associated with the label.
  • Put up an alert box with the error message.
  • Blink the error, whether its textual or an image, one or more times after the error is detected.
Problem

Users often click the submit button several times before noticing that there is a validation error that prevents the page from submitting.

Solution

While you can show an alert immediately when the user attempts to submit, if your page design does not use this technique, the alert can automatically appear after several clicks on the submit button.

Problem

A consistent set of error messages is preferred across a site. Since users have to enter the ErrorMessage property each time, error messages may not be consistent.

Solution

Peter's Professional Validation includes a String Lookup System that can use resource (.resx) files, databases and other data sources. Most string type properties include a corresponding LookupID property where you define an identifier that will look for a string in your data source. This system supports localization, by using the culture of the current web page as it looks up strings.

Problem

Error messages cannot contain runtime information such as the current value of the field that caused the error. Error messages cannot automatically embed design time properties such as the minimum or a label associated with the textbox.

Solution

Peter's Professional Validation defines tokens that you enter into the error messages. When you define error messages in the String Lookup System, tokens automatically customize error messages to each situation. Here are the types of tokens:
  • Values determined at runtime. For example, the TextLengthValidator offers the token "{COUNT}". When found, it is replaced by the actual number of characters you typed. The WordCountValidator, CountTrueConditionsValidator, and CountSelectionsValidator all can show the count. The DifferenceValidator can show by how much the two fields are apart. Most validators offer the "{TEXTVALUE}" token to show the current value of the field within the error message.
  • Values determined at design time in the control’s properties. For example, all validators with a Minimum and Maxmium property offer the tokens "{MINIMUM}" and "{MAXIMUM}". Use these within strings you define in the String Lookup System so that each string shows relevant data without having the programmer to edit the error message directly.
  • Often sentences that show a numeric value have to have two forms, one for singular and one for plural usage of the number. ("There is 1 word." or "There are 2 words."). DES offers tokens that allow you to define both the singular and plural forms. For example, those with "{COUNT}" also support "{COUNT:singular:plural}". Define the message like this: "There {COUNT:is:are} {COUNT} {COUNT:word:words}."
  • You can define a label that names the field using the new Label property on each Validator control. Then use the "{LABEL}" token to show it in the error message. Labels can be actual controls or text that you define within the Label property. DES provides case changing rules to convert control fields to a more readable format for the error message such as "lowercase", "uppercase", "sentence style", and "title style".
You can define global styles for tokens so that the labels, runtime and property values stand out.
Problem

The list of data types that can be evaluated is fixed. You cannot extend the system to handle new data types or customize the data types to fit your needs better.

Solution

Any Validator control that translates text into a particular data type supports a customizable list of data types. The predefined list includes String, String-Case Insensitive, Integer, Double, Date, Currency, Currency with Symbol, Percent, Percent with Symbol, Positive Integer, Positive Double, Positive Currency, and Positive Currency with Symbol. (With Peter's Date and Time module, this list is expanded to support time of day and duration.) You can define new data types programmatically in a similar way to the TypeConverter classes.

Problem

You can only attach the ControlToValidate property to a control within the same naming container. For example, if your validator is in a User Control, it must point to another component in that UserControl.

Solution

Peter's Professional Validation provides an alternative property where you can attach a reference to a control found in any naming container.

Problem

When using a CustomValidator, you may evaluate more than 1 data entry field. You want a change to any of the data entry fields to run the validator. Microsoft only runs the validator on the control assigned in the ControlToValidate property.

Solution

DES's CustomValidator supports as many fields as you need.

Problem

When using a CustomValidator, you are forced to locate the evaluation logic into the custom validator event handler method. Sometimes it makes more sense just to set the Validator's IsValid property within existing code.

Solution

DES's IgnoreConditionValidator lets you do this. Suppose you write code to save a record in a button's Click event. That code interacts with your database to prepare the data that will be written. During that preparation, you find an error. A validator is the perfect tool to communicate it back to the user. The CustomValidator requires that you relocate that logic, perhaps even doing extra work on the server. The IgnoreConditionValidator keeps the code in one place.

Problem

When using a CustomValidator and want to evaluate when a textbox is empty, you must not use the ControlToValidate property.

Solution

DES's CustomValidator will run when its ControlIDToEvaluate property is assigned to a TextBox that is empty.

Problem

The RegularExpressionValidator does not run when the textbox is empty. Sometimes you build regular expressions that evaluate this state.

Solution

DES's RegexValidator has a property to enable the ability to evaluate when the textbox is empty.

Problem

The ValidationSummary is far away from the errors. There needs to be a way to get the error message connected to the field.

Solution

The HyperLinkToField property enables hyperlinks on each error message. When the hyperlink is clicked, focus moves to the field with that error.

Problem

When the user clicks Submit, the ValidationSummary is offscreen and the user needs to scroll to see it.

Solution

The ScrollIntoView property causes the page to automatically scroll to show the ValidationSummary.

Problem

The ValidationSummary continues to show all of the errors that the user fixes until they click Submit. It confuses the user to see errors they have resolved.

Solution

The AutoUpdate property lets the ValidationSummary refresh as errors have been fixed. If all fields are fixed, it automatically disappears.

Problem

Users want the ValidationSummary control to show only the header text without any validator error messages. This lets the ValidationSummary be a simple message to fix the fields with the error.

Solution

DES's ValidationSummary control can hide the error messages by setting its DisplayMode property to None. It also can be attached to a second control like a Label, that is shown and hidden as the ValidationSummary is. This allows you to put a message on the page and still show the ValidationSummary elsewhere.

Problem

The Required field errors should use a different style sheet on their error messages to associate color with usage.

Solution

Validators can be marked to use an alternative style sheet class on their error messages shown in the ValidationSummary. They can change the background color of the data entry control to a different color from the rest.

Problem

CustomValidators that lack client-side code cannot show their message in the optional alert when you submit (using the ValidationSummary.ShowMessageBox).

Solution

DES's ShowAlertOnSubmit feature will show the alert after post back detects an error found by a server-side only validator.

Problem

When you click a Reset button, validators are not restored to their original state.

Solution

DES handles Reset properly, restoring validators to their original state.

Problem

You cannot hook up javascript code that runs after the client-side validation has run and approved the validators.

Solution

DES provides a hook for your javascript code.

Problem

Users want to prompt to save the page when the submit button is clicked.

Solution

DES lets you have a confirm message and determine if it goes before validating or after.

Problem

The client-side JavaScript is not extendable. While you can write JavaScript for each CustomValidator, you cannot add new features to the client-side framework such as data types, formatting, or support for new controls.

Solution

The JavaScript within Peter's Professional Validation is designed in a more object oriented way. Many functions are actually associated with properties on JavaScript objects, becoming methods. There is documentation to show the format of each method and how to install it, to replace the existing functionality.

The server-side objects are also much more extendable. You can define new Error Formatters, Conditions, and Data Types and use them in the existing controls. Microsoft designed its BaseValidator class with all the concepts – format (subclassed from the Label webcontrol), datatypes and condition – in one class.

Problem

In ASP.NET 1.x, client-side code only works on DHTML supported browsers. Internet Explorer on Windows and Macintosh work automatically. A few other browsers that support DHTML need require extra setup to support client-side scripting. No Netscape or Mozilla browser is supported.

Solution

Peter's Professional Validation includes support for both DHTML and DOM. It is smart enough to smoothly scale down when a browser doesn’t support a feature. You don't need to take extra steps to support a non-Internet Explorer browser. Client-side validation is supported IE, IE/Mac, FireFox, Netscape 7, Mozilla, Opera 7+, Safari, Chrome, Camino (Mac), and OmniWeb (Mac).




Peter's Data Entry Suite gives you feature rich and interactive data entry web forms with over 100 web controls.
Start with better controls. Finish with better sites.
Try It   Buy It
Related products: Peter's Data Entry Suite  | Peter's Business Logic Driven UI ("BLD")  | Peter's Professional Validation  | Peter's More Validators
Peter's Date and Time  | Peter's TextBoxes  | Peter's Interactive Pages  | Peter's Input Security