Validating form data is something which must always take place on the server side, but for efficiency reason we may wish to use client-side validation in addition to that. It will benefit users by giving quicker feedback and it will benefit us because it reduces the number of requests to our servers.
AJAX became an important buzzword last year. Everyone must use it, whether they really needed it or not. Sometimes I get the feeling that it is an answer in search of a problem, but there is no denying that it is a useful technique for some common situations.
Consider a form with two or more
select elements (drop-down lists or list boxes) where each
select is dependent on the previous one. Typical examples are drill-down choices for type/subtype or country/state. Depending on what you select in the first list, the content of the second list should change. How can we make this work as well as possible for all users?
We will once again begin with the basics. Do not think about client-side scripting at this stage; think only about HTML support:
Example Eight (in HTML) <form action="products.php" method="post"> <fieldset> <legend>Product Type</legend> <label for="type">Type</label> <select name="type" id=”type”> <option value="none" selected>- select a type -</option> <option value="widgets">Widgets</option> <option value="gadgets">Gadgets</option> </select> <input type="submit" name="chooseType" value="Select"> <br> <label for="subtype">Subtype</label> <select name="subtype" id="subtype" disabled> <option></option> </select> <br> <input type="submit" name="show" value="Show Products" disabled> </fieldset> </form>
Our primary list (Type) is populated with our product types: widgets and gadgets. The secondary list (Subtype) is empty and disabled, and the main submit button (Show Products) is disabled. A user needs to choose a product type and then activate the other submit button (”Select”). The form is submitted to our server-side script (products.php), which will then redisplay the form with the subtype list populated with the subtypes of the selected type (or a friendly error message if no type was specified).
The user can then select a subtype and submit the form using the “Show Products” button (which is not disabled this time). If she changes her mind and wants to select another type, she will have to activate the “Select” button again to load the correct subtypes.
This is not the most user friendly form in the world, and it needs some rather tedious (but straightforward) server-side scripting, but it works in virtually all browsers. Even Lynx handles forms like this one.
attachEvent(), depending on the user’s browser. Then we would remove the “Select” button using the
removeChild() DOM function, because it is no longer necessary and would only be confusing.
The added event listener would open an asynchronous connection to our server and post an HTTP request specifying the selected type. The server script would query the database and return an XML reply containing the available subtypes, which we would then parse and use to populate the subtype list (with DOM functions). Then we could enable the subtype list and the main submit button.
This is progressive enhancement: it works for everyone, but users with modern browsers will see a more usable version. We are, in a way, rewarding them for choosing to use a good browser, without being rude to Lynx users or employees of companies with paranoid IT departments. We don’t even have to trust the unreliable