Creating Responsive GUIs with Real-Time Validation | Page 2

[previous] [next]

Creating Responsive GUIs with Real-Time Validation

The Design: Designing a Validator Application

The design of the Validator application is hopefully a little more obvious than some of the other applications in the book, primarily because discrete pieces of user input data are validated independently of one another. Your design job is basically just to call the appropriate validatekit.js validation function for each user-input text box. Then there is the Ajax request that provides an additional level of validation for ZIP codes by looking up the city and state from a Web service.

Figure 7.1 shows a rough interpretation of the user interface for the application, which reveals how the help fields are arranged next to each input text box.

You can see in the figure how each text box is associated with a particular kind of data, such as a phone number, an email address, etc. The help field next to each text box is used to convey help information about the validity of the data in that text box. The only exception is the help field for the ZIP code, which serves double duty as a display field for the city and state retrieved via an Ajax request.

Speaking of the Ajax request for the ZIP field, it would be quite handy to display an animated "loading" image to let the user know that the application is busy looking up the city and state based upon the ZIP code. This image, wait.gif, is shown in Figure 7.2.

The "loading" image is displayed in the same field that holds the help text for the ZIP code, which I suppose makes the field actually perform triple duty. The following three pieces of information are capable of appearing in the ZIP code's help field at different times throughout the process of entering a ZIP code:

Help text is shown when the ZIP code is invalid. The "loading" image is shown while an Ajax request is being carried out. The dynamically loaded city and state are shown after a successful Ajax request.

This may seem like a lot of stuff is going on with respect to the ZIP code and its helper field, but the Validator application handles it all without much complication. Keep in mind that the application is really only dealing with one Ajax request, which also helps to simplify things. You're now ready to learn a little more about the ZIP code Ajax request.

The Client Request

The client request for the Validator application is very basic in that it sends along the ZIP code when the ZIP code text-input control loses focus. This approach is very different from the Completer application in Chapter 6, "Reading the User's Mind with Auto-Complete," which issues an Ajax request after each individual character is typed. The character-by-character request technique doesn't make sense for Validator because it takes multiple keypresses to enter a meaningful piece of data in Validator—you must wait until the user is finished entering the data before attempting a validation. Your cue that the user is finished entering data in the ZIP code input control is when he or she leaves the control by tabbing away from it or clicking off of it.

Once the user has left the ZIP code text box, you're free to send along the input as part of an Ajax request. This user input is just raw characters of text without any special formatting. The integer validation that has already been performed does ensure that the ZIP code text consists of five integer characters, but the text is still considered unformatted in a sense that it isn't encoded in XML or any other standard data format.

Note: I realize there is a longer ZIP code format of the form #####-#### that could feasibly enter the picture here. To keep things simple, I've opted to stick with the basic five-digit ZIP code, which has the form #####.

That's all you need to know about the minimal amount of data sent from the client to the server for a ZIP code lookup. Let's now address what the server sends back.

The Server Response

The Ajax server response in the Validator application returns information about the ZIP code sent over in the request. This response is indirectly received from a third party Web service, webserviceX.net, that offers several handy data feeds in XML format. In this case, the webserviceX.net service uses a ZIP code to look up and return a matching city, state, area code, and time zone. Since all you need in the Validator application is the city and state, you can ignore the area code and time zone. The fact that the response data is formatted as XML code makes it easy to access only the specific data you need.

You may recall from some of the earlier applications that you can't make an Ajax request on a third-party domain. Therefore, the trick is to alleviate this security limitation by making the third-party data request from a server script, and then using Ajax to get the data from that script, which resides on your server. This works because there isn't a security issue with requesting data from a server script. So the Validator application needs to include a PHP server script that serves as a proxy for making ZIP code requests to the webserviceX.net service.

Making Sense of the Client-to-Server Conversation

The Ajax request within the Validator application is used to shuttle a user-entered ZIP code to the server and then receive a city and state in return. Figure 7.3 helps to clarify this transfer of data visually.

The data sent to the server as a parameter of the Ajax request is a ZIP code that has been entered by the user. The ZIP code has already been validated in terms of its format but has not been checked to make sure it really matches up with a city and state. ZIP code requests are handled by the ziplookup.php server script. Following is an example of an Ajax request URL that sends along the ZIP code 85250 as the only parameter to the server script:

This code reveals how the ZIP code is packaged into a URL as a single parameter (zipCode). This entire URL is used as the basis for an Ajax request, in which case your server script, ziplookup.php, will take the zipCode parameter and use the URL it contains to obtain the city and state information.

The city and state data is returned as a compact XML document that actually contains the city, state, area code, and time zone for the ZIP code, assuming the ZIP code is successfully matched. Following is an example of what such an XML document actually looks like:

Even if you aren't an XML guru, this code isn't too terribly hard to figure out. You're really only interested in the <CITY> and <STATE> tags because they contain the city and state for the ZIP code. The remaining task is then to extract the city and state from this data on the client.

[previous] [next]

URL: