Validation is essential to web database applications. Ensuring that data meets user and system requirements is important, but ensuring that the database constraints are met by the data is critical. There are three possible data environments in which validation can occur in a three-tiered web database application: in the DBMS, in server-side scripts, and on the client. We discuss the merits and possibilities of these approaches to validation in this chapter.
As the name suggests, client-tier validation occurs at the client
browser before a request is sent to the server and is usually
validation of <form>
data. The most common
way to implement client-tier validation is using the scripting
language best known as JavaScript. JavaScript
isn’t a fully fledged programming language, but
it’s one that can be effectively used for simple
tasks such as validation. The drawback of validation at the client is
that it depends on the user and his environment: the user can disable
JavaScript, and can willfully or passively circumvent the validation,
and the client environment isn’t usually managed or
standardized by the developer of the web database application.
Server-side validation is usually performed in a middle-tier script and is the essential validation tool. When data is inserted, updated, or deleted at the DBMS, it’s undesirable to rely on the constraint-checking validation implicitly performed by the DBMS in the database tier. Trapping errors using the PHP MySQL error functions is difficult, has unnecessary network and DBMS overhead, and is hard to present to the user in a meaningful way. A much better approach is to use the middle-tier PHP scripts to validate data and ensure that all constraints of the database are met before modifying the database.
In this chapter, we extend our discussion of validation in PHP. We
have already introduced basic validation principles in Chapter 5 with the clean( )
function for security and in Chapter 6 with the
field empty( )
checks used before modifying the
customer table. We extend those discussions here
by introducing the principles of validation and the practice of
validating <form>
variables and values with
PHP. We use the customer <form>
we developed
in Chapter 6 as our case study. We then consider
in more detail the variables and values that are sent from a browser
to a server, their variations, and the traps to watch for.
After discussing server-side validation, we discuss client-side JavaScript and how simple validation can be performed at the client to save network costs and improve responsiveness of an application to the user. We also introduce other simple tasks that can be effectively accomplished with JavaScript.
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 correct 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 it can be post-validation, where the data is checked after entry. Presenting errors can be field-by-field—where a new error message is presented to the user for each error found—or 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:
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.
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 normally the user can’t proceed beyond the current page without fixing all errors.
The user first enters all data with no validation. The data is then checked and errors are reported field-by-field in separate error messages to the user. Usually, for each error, the cursor is placed in the field requiring amendment.
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 6—without discussing the
details—we 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 string. In the case study
example in this chapter, we discuss additional validation for the
customer <form>
data to more carefully
inspect both mandatory and optional fields. The completed validation
code is listed in Chapter 10.
Interactive models are difficult to implement in the web environment. Server-side scripts are impractical for this task, since 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, 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 should not be the only method of validation
because—as we emphasized in Chapter 5—the user can passively or actively avoid
the client-side processes. We discuss the partially interactive
solution of including client-side scripts with an HTML
<form>
later in this chapter.
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. If this validation
succeeds, data is submitted to the server and the same—or 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.
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.
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 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. The disadvantage is that the cursor can’t easily be directed to the field requiring correction.
Server-side validation is essential to secure a web database and to ensure that system and DBMS constraints are met.
Client-side validation may be implemented in addition to server-side validation, but all client-side functionality should be duplicated at the server side. Never trust the user or the client browser.
The choice of which reporting model to use depends on the size and
complexity of the <form>
and on the system
requirements.
In the next section, we introduce the practice of server-side post-validation using the batch error reporting method. We introduce client-side scripting as a tool for validation and error reporting in Section 7.3.
18.119.29.105