Creating Responsive GUIs with Real-Time Validation | Page 4

[previous] [next]

Creating Responsive GUIs with Real-Time Validation

The ZIP Lookup Server Script

Similar to the Picker application from Chapter 4, "Using Ajax to Dynamically Populate Lists: A Stock Picker," Validator requires a script on the server side to sidestep the limitation of not being able to make a direct Ajax client request on a third-party domain. The third-party domain is important because the Validator application relies on it for looking up ZIP codes. The Validator PHP script serves as somewhat of a security proxy by accepting an Ajax request on behalf of the client, retrieving the city/state data from the third-party server, and then responding to the client with the data. In this way, the Ajax request itself is made on your own domain, which is perfectly acceptable given the security constraints of Ajax.

The third-party Web service I'm talking about is webserviceX.net, which offers several XML-based data feeds. The Picker application in Chapter 4 uses this service to obtain live stock quotes, whereas Validator uses it to obtain detailed information about a ZIP code. In this case you specify a ZIP code, and the server responds with an XML document containing detailed information about it, including the city and state associated with it. You've already seen the code within this XML document, but you haven't seen the PHP script that makes it possible to receive the code via an Ajax request. Following is the code for the ziplookup.php server script:

<?php header('Content-Type: text/xml'); // Load the XML location data from the server $xml = html_entity_decode(file_get_contents( "https://www.webservicex.net/uszip.asmx/GetInfoByZIP?USZip=" . $_REQUEST['zipCode'])); // Return the XML location data echo $xml; ?>

Keep in mind that the job of this script is to retrieve an XML document from the ZIP code Web service at webserviceX.net, and then simply pass that data along to the client without any modifications. It is then up to the client to do something useful with the XML code, such as display the city and state on the page.

The server script begins by making sure that the response gets treated as XML. It then loads the XML document from the ZIP code Web service, making sure to pass along the zipCode parameter so that the Web service knows which ZIP code to look up. The script concludes by returning the XML data from the script, which serves as the response to the Ajax ZIP code request.

Although I'm sure you're itching to test out the application, let's take a second to test the PHP script by itself. You saw how this is done in earlier chapters by opening PHP scripts directly in a browser—here's a sample URL for testing the ZIPLookUp script:

Assuming the ziplookup.php file is stored on your server, change the domain to match yours in this line of code and then enter the URL into your Web browser. Figure 7.5 shows the XML response data generated by the PHP script.

It's definitely worth experimenting with the ZIP codes passed into the script via the URL to see how they impact the XML data that is returned. You should always test PHP scripts directly in this manner to make sure their results are consistent with what you expected—it's much tougher to diagnose server script problems when all you're looking at is the client Web page.

Testing Validator

The Validator application presents an interesting testing opportunity because you have several different data fields to tinker with as you check the effectiveness of the validation. You'll notice that the data types tend to progress in complexity as you move down the page. It's easy to generate a help message by either entering nothing or entering invalid data into any of the input controls, and then tabbing off of the control. Figure 7.6 shows a help message being displayed next to invalid integer data.

Of course, the text "more data" doesn't exactly constitute a valid integer, which explains the help message in the figure.

Things get more interesting as you experiment with entering data into more complex types, such as the date input control. Figure 7.7 shows an invalid date message displayed in response to a nearly valid date.

Obviously the month of January only has 31 days, so a date involving the 32nd day of the month is invalid in this example. The Validator application catches the input error and displays a help message.

Although date validation is handy, the most intriguing part of the Validator application is the lookup of ZIP codes, which takes place when you enter a ZIP code into the ZIP code input control and then leave the control. Figure 7.8 shows the animated "loading" image displayed as the ZIP code Ajax request is being carried out.

Yeah, I know, I couldn't resist using the most popular ZIP code on Earth to test out the application. If the ZIP code data is successfully retrieved via the Ajax request, the resulting city and state are displayed in place of the "loading" image, as shown in Figure 7.9.

Success is great, but what happens when a ZIP code isn't found? If you recall in the code for the application, a help message is displayed to indicate this. Figure 7.10 shows the help message displayed in response to a ZIP code that isn't associated with a real city and state.

It's important to note that a ZIP code that isn't found isn't necessarily invalid in a strict data entry sense. Yes, it isn't in use in the real world, which is a problem if you're entering a shipping address, for example, but that doesn't mean it won't be real someday. ZIP codes are not etched in stone, and in fact they are created anew on a fairly regular basis in fast-growing areas. That's the beauty of relying on a third-party service to handle the ZIP code lookup—it is responsible for keeping its ZIP code database up to date, not you.

Regardless of how you handle the issue of a ZIP code not being used in the real world, hopefully you can see how the Validator application lays some important groundwork in data validation that you can reuse and repurpose in all kinds of useful ways.

[previous] [next]

URL: