One solution you can develop is a company directory. Let's say that you've already provided your company with an internal directory, and now you want to open that directory up to other possible users (e.g., vendors, suppliers, etc.). Before doing so, you should understand how WML works.
How WML works
WML is based on a deck-of-cards concept, in which you control how many cards are
within a deck. When a mobile device makes a request to the WAP server, it requests
a deck rather than a page. This deck is loaded in the mobile device, and the
user can navigate between cards without requiring another request to the server.
WML is similar to HTML, except WML is based on the XML 1.0 standard, so tags are case-sensitive and all tags require closing tags. WML is also stricter than HTML with a smaller set of tags available. Also, the user of tables and images is restricted.
Creating a solution
First, figure out what functionality you want to provide your users. Be sure
to keep in mind how much information is necessary to make your wireless solution
navigable without incurring too much traffic; also, remember that your users
have to pay for airtime.
In my case, I want the user to be able to look up employee information based on last name, first name, location, or department. For first name or last name, it only requires the user input the first or last name of the person for whom they're searching. However, for location or department, the user will get a list of options.
WML files based on the WML 1.1 standard begin with the following:
<?xml version="1.0"?>
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"
"http://www.wapforum.org/DTD/wml_1.1.xml">
This specifies that it's an XML document and a WML doctype. A deck is composed
of the following:
. . .
<wml>
<card/>
</wml>
Let's start with our first deck:
. . .
<wml>
<card id="main" title="Directory" newcontext="true">
<p>
Search By...<br/>
<anchor>Last Name
<go href="#ln"/>
</anchor><br/>
<anchor>First Name
<go href="#fn"/>
</anchor><br/>
<anchor>Location
<go href="search.asp" method="post">
<postfield name="qt" value="loc"/>
<postfield name="qv" value=""/>
</go>
</anchor><br/>
<anchor>Department
<go href="search.asp" method="post">
<postfield name="qt" value="dpt"/>
<postfield name="qv" value=""/>
</go>
</anchor><br/>
</p>
</card>
<card id="ln" title="Last Name">
<p>
Enter Last Name:<br/>
<input name="qv"/>
</p>
<p>
<anchor>Submit
<go href="search.asp" method="post">
<postfield name="qt" value="ln"/>
<postfield name="qv" value="$qv"/>
</go>
</anchor>
</p>
</card>
<card id="fn" title="First Name">
<p>
Enter First Name:<br/>
<input name="qv"/>
</p>
<p>
<anchor>Submit
<go href="search.asp" method="post">
<postfield name="qt" value="fn"/>
<postfield name="qv" value="$qv"/>
</go>
</anchor>
</p>
</card>
</wml>
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.
In the next article, 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.
Phillip Perkins is a contractor with Ajilon Consulting. His experience ranges
from machine control and client server to corporate intranet applications.
You can view the second part of this article here
Do you need help with Embedded/Mobile? 
Leave a comment