لطفا منتظر باشید ...
9.1 Validation and Error Reporting Principles
There is nothing worse for a user than
annoying, overly persistent, inaccurate, or uninformative validation.
For example, error messages that describe an error but
don't specify which field contains the error are
difficult to correct. However, there is no recipe for balancing
validation with system requirements: what is pleasing or mandated by
requirements in one application might be annoying or useless in
another. In this section, we consider practical validation models for
web database applications.
Validation is actually two
processes: finding errors and presenting error messages. Finding
errors can be interactive, where data is checked
as it's entered, or
post-validation, where the data is checked after
entry. Presenting errors can be
field-by-fieldwhere a new error message
is presented to the user for each error foundor it can be
batched, where all errors are presented as a
single message. There are other dimensions to validation and error
processing, such as the degree of error that is
tolerated and the experience level of the user.
However, considering only the basic processes, the choice of when to
error-check and when to notify the user, leads to four common
approaches:
Interactive validation with field-by-field errors
The data in each field is validated when the user exits or changes
the field. If there is an error, the user is alerted to that error
and may be required to fix the error before proceeding.
Interactive validation with batched errors
The data in all fields is validated when the user leaves one field.
If there are one or more errors, the user is alerted to these, and
can't proceed beyond the current page without fixing
all errors.
Post-validation with field-by-field errors
The user
first enters all data with no validation. The data is then checked
and errors are reported for each field, one by one. The user fixes
each error in turn and resubmits the data for revalidation.
Post-validation with batched errors
The user first enters all data with no validation. The data is then
checked, and all errors in the data are reported in one message to
the user. The user then fixes all errors and resubmits the data for
revalidation.
In Chapter 8without discussing the
detailswe covered several simple post-validation techniques to
check whether mandatory form data was entered before inserting or
updating data in the database. In addition, we used a batch reporting
method, where errors were reported as a list by constructing an error
page using a template.In the examples in this chapter, we discuss additional validation
techniques to inspect both mandatory and optional fields. We use
these techniques to create a batch error report in Chapter 10. Examples of complete validation code for a
customer details form are listed in Chapter 17.
9.1.1 Models That Don't Work
Interactive models are difficult
to implement in the web environment. Server-side scripts are
impractical for this task, because an HTTP request and response is
required to validate each field that's entered. This
is usually unacceptable, because the user is required to submit the
data after entering each field. The result is that response times are
likely to be slow and the server load high.Client-side scripts can implement an interactive model. However,
validation on the client side should not be the only method of
validation because the user can passively or actively bypass the
client-side processes. We discuss the partially interactive solution
of including client-side scripts with an HTML form later in this
chapter.
9.1.2 Models That Do Work
Post-validation models are practical in
web database applications. Both client- and server-side scripts can
validate all form data during the submission process.In many applications, reasonably comprehensive validation is
performed on the client side when the user clicks the form submit
button.
Client-side validation reduces server
and network load, because the user's browser ensures
the data is valid prior to the HTTP request. Client-side validation
is also usually faster for the user.If client-side validation succeeds, data is submitted to the server
and the same (or often more comprehensive) validation is performed.
Duplicating client validation on the server is essential because of
the unreliability of client-side scripts and lack of control over the
client environment.The post-validation model can be combined with either field-by-field
or batch error reporting. For server-side validation, the batch model
is preferable to a field-by-field implementation, as the latter
approach has more overhead and is usually slower because each form
error requires an additional HTTP request and response.For client-side post-validation, either error-reporting model can be
used. The advantage of the field-by-field model is that it leads the
user through the process of correcting the data and the cursor can be
directed to the field containing the error, making error correction
easier. The disadvantage is that several errors require several error
messages, and this can be frustrating for the user. The advantage of
the batch approach is that all errors are presented in one message
but the disadvantage is that the cursor can't easily
be directed to the field requiring correction and its sometimes
unclear to the user how to correct the data.
