One of my favorite parts of Web applications development is user interface design. My primary concern is with the flow of a page as opposed to how pretty it is. There is nothing more frustrating than having clients make their selections, click a button, and then wait for an entire unload-reload cycle only to be told that they forgot their zip/postal code. What the world needs is a common routine that would perform the basic “is there data?” check.
I am a firm believer in the use of bound XML data islands, mostly because XML provides a way of keeping all of the data in one convenient package. This data can then be put in a SOAP wrapper and shipped off to the server via XMLHTTP. Also, because of the binding, changes to the values of the bound XML immediately reflect themselves in the HTML objects and vice versa. So, I decided to incorporate XML data islands into the design.
While the common edit routine is pretty good for most purposes, it isn’t really enough for someone like myself who has the typing skills of a chicken. What’s needed is an uber-edit routine that does more than a simple “is there data?” check. After all, there is a big difference between data and bad data (if you’re a Star Trek fan just think Data and Lore). Some kind of data validation is also needed.
Currently the way that client-side data validation is performed is through the basic “does that data look the way that I want it?” check. This is done on an input-by-input basis, and while it’s great because you get to write a lot of custom code for each page, it also stinks because you have to write a lot of custom code for each page. This process is extremely error-prone and uses time that could be better spent on other tasks.
As with the common edit function, the uber-edit will test to determine if required inputs actually have values, but the uber-edit function won’t stop there. Since its purpose is to greatly reduce the amount of custom client-side code it only makes sense that it incorporates every edit that I can think of. This is invoked through the use of the format attribute. Specifying a format attribute of “numeric” causes the bound node to be tested for numeric data. These numeric objects can also be tested to determine if their value is greater than zero. In addition to the numeric test, a test for a valid date is also built in.
In an effort to avoid the “oops, I didn’t think of that!” that usually occurs about the same time as the code is fully tested, I added the function attribute. The function attribute invokes a function external to the XML edit function and passes the associated node’s value. This external function then performs its custom edits and returns either a true for a good return or a false for a bad return.
In the United States, a big part of shipping information is the zip code which consists of five digits representing a geographic location and an optional four digits covering streets and carrier routes. Carriers won’t even look at a package that doesn’t have at least a five-digit zip code. An interesting and obscure thing about zip codes is that they cover the states and territories in ranges. For example, Pennsylvania’s zip codes range from 15001 to 19640. Certain states, such as New York, have more than one range due to their economic and population growth since the zip code system was created.
Canada’s postal codes, on the other hand, are six characters, consisting of alternating alpha and then numeric pairs. The alpha portion represents the province, and therefore, is not comprised of the complete alphabet. The easiest way to test for this combination is through the regular expression shown in Listing C.
Due to their length, Listing D and Listing E have been compressed into a ZIP file that we have made available thru Builder Downloads.
The final result of the zip/postal code external edit is shown in Listing D. Please note that there has been logic added to the MozillaDSO() function to bind HTML select objects.
Because the majority of the order entry screens that I work with consist of row after row of tabular information, being able to verify that each row is complete is a big part of the client-side edits that I code. In keeping with my theme of not having to type any more than necessary, I decided to try my xmlEdit function on bound tabular information. Due to the nature of the information, this application presents a unique change.
First, tabular information is a bit like having a number of individual, interrelated pages. Each line must be either totally complete or totally empty; no half measures are allowed. Fortunately, with a little work, an external edit can handle this task. However, like the zip/postal code edit there is code that will be custom written for each page.
The starting point is a basic order-line-entry page that is a throwback to the days of 3270 displays and IMS; its purpose is only to provide a proof of concept. The inputs consist of three text boxes: part number, quantity, and customer part number. For a line to be complete, there must be a quantity and either a part number or a customer part number. Users also have the option of leaving an input line blank, all of which is pretty basic stuff.
Listing E shows the finished external edit which does require some custom code, but not nearly as much as a typical application.
In addition to cutting down on the amount of typing when developing new Web-based applications, changes to the page edits can be accomplished with relative ease. What in the past has required a major overhaul of the client side when business rules changed can now be a quick modification and test.