What this code creates
When the first card displays on the phone, it shows a list of search options. Each of these options is an <anchor> with an associated <go> tag. The <go> tags tell the microbrowser where to go. Any href beginning with # refers to another card within the current deck; otherwise, it refers to another WML file.
When you click on First Name or Last Name, the microbrowser navigates to the associated cards in the deck. However, if you click on Location or Department, the microbrowser will request the WML located at "search.asp". This is necessary because we're going to provide the user with a list of either locations or departments from which to select as search criteria. The reason for separating this is because the phone's resources are limited, and there's no reason to inundate the phone with data that may or may not be used. If the user selects Location or Department, we can supply that data at that time.
The Last Name and First Name cards contain an <input> element and another <anchor> to submit the search data to the server. If you notice in the <go> element on the Last Name and First Name cards, there are a couple of <postfield> elements that are used to send data to the server. The <input> elements in WML are used to set global variables with the same names as the <input> name attribute. This is a big difference from the way normal HTML pages work. When you want to submit this data to the server, you create <postfield> elements and set their values using WML variables. You'll notice the value of the "qv" <postfield> element is set to "$qv". You refer to the variables in this manner.
Once you have the necessary data, you pass that data through the <go> element back to the server. It's a good practice to use the method attribute of the <go> element to submit data as post data.
Next, I'll collect the data and provide a return WML page to provide the locations and departments and to provide a list of results from the search criteria. Clicking on an element in the results list will return full information for that particular directory entry.The ASP page takes the form input from the mobile device and uses that
information to provide a list of results from the search. However, for
the location and department searches, a list of locations and
departments are provided if one hasn't already been selected.
I'm using a Microsoft Access database as the underlying data. Here's
the code to take the search criteria and create the output necessary:
First, this page sets the Content-type of the response to "text/vnd.wap.wml", which is the MIME-type that mobile devices (and WAP gateways) understand. Then, I open a connection to the database through ADO. I create a couple of local variables to hold my query type (qt) and query value (qv) form values. Then, I write out the top portion of the WML page to the Response buffer.
In the next bunch of VBScript, I check the query type for the appropriate action. If the query type is "loc" for location, I check the query value variable to see if it's set. If the query type isn't "loc", I return a list from which the user will select a location. Then I do the same thing for "dpt" or department.
When the user enters the query type and query value, I create a list of anchors from the names in the data; this is also true for last name and first name search. Because of the limitations of WAP and WML, I restrict my output to five names. If there are more than five names in the result set, I pass another anchor that says "More. . .". This anchor also provides the last identity column from the underlying data. This information is used to supply the next group of results from the query.
When the user selects the name anchor, they're sent to the final page that displays the information on the selected name. Here's the code that accomplishes this:
This code looks into the underlying data to find the person that matches the identity column data (tblPhone.phone_id). The result is a line that displays the person's name, a line for the phone number, a line for the department, and a line for the location. I also provide the phone number in an <input> element, so when the user focuses on this field, the user's phone may give them the option to use that number.
When you provide your output as the result of a scripting language such as ASP, you need to set the Content-type on the result; this lets the WAP gateway know that it's dealing with WML data. Also, keep your information to a minimum, since phones' resources may be limited.
In order to create this code and test it without incurring severe cell phone charges, I used the downloadable Nokia Mobile Internet Toolkit (which is listed under the Content Authoring heading).
Phillip Perkins is a contractor with Ajilon Consulting. His experience ranges from machine control and client server to corporate intranet applications.