|
Addressing 30 Limitations of Microsoft's Validation Framework
|
|
Peter's Data Entry Suite Overview
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".
Demo
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.
Demo
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.
Demo
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.
Demo
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.
Demo
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, Camino (Mac), OmniWeb (Mac), and Safari (Mac).
Peter's Data Entry Suite gives you feature rich
and interactive data entry web forms with over 70 web controls.
Start with better controls. Finish with better sites. |
|
Peter's Data Entry Suite Overview
|