|
Addressing 30 Limitations of Microsoft's Validation Framework
|
Try It
Buy It
|
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".
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
|
Peter's Data Entry Suite Overview