Under the Covers of the Employee White Pages WAP Application
When we started writing wireless applications, we discovered that they're just ASP files. Because WML has a smaller implementation than HTML and rigid and unforgiving rules of structure, writing wireless applications is fairly easy.
The first ASP file that executes in Employee White Pages is select_employees.asp, which Listing 1, page 4, shows.
Select_employees.asp renders WML to let the user choose which list of employees will appear on the WAP device. The first four statements use the Response object, as callout A in Listing 1 shows. The ContentType property of the Response object identifies the MIME type as WML for a WAP device. This statement is common to all the ASP files in the application. The next two statements use the addHeader property to add data to the HTTP header, which prevents the WAP device from caching the pages. By default, WAP devices cache everything they possibly can because, by nature, they have bandwidth restrictions. Finally, the Expires property of the
Response object sets the expiration value to 0. The expiration value specifies when the data in the user's cache for this WML page becomes invalid. This value is based on minutes. In this case, 0 means the data automatically expires.
In Select_employees.asp, the code
<?xml version="1.0"?>
<!DOCTYPE wml PUBLIC _
"-//WAPFORUM//DTD WML _
1.1//EN"
"http://www.wapforum.org/
DTD/wml_1.1.xml">
defines the XML Document Type Definition (DTD) for WML. All WML files are in XML format. This DTD describes the structure of the XML document. WAP-enabled browsers understand this format of an XML document, and the DTD provides the definition to the document.
The rest of the ASP page is the XML-formatted WML document. The <wml> tag wraps the body of the document. The <card> tag wraps the content that is actually rendered to the WAP device. Figure 6 shows the results of select_employees.asp.
Now, let's look at employees.asp, which Web Listing 1 shows. Employees.asp is the heavy lifter for the WAP application. The structure and format of this ASP page is the same as the structure and format of select_employees.asp. The HTTP header information, the DTD, and the WML format (i.e., <wml> and <card> tags) are identical. What's different in this page is that we use the group returned by the select_employees.asp page with the Request object's QueryString property to display a list of employees in WML, as callout A in Web Listing 1 shows.
The ActiveX Data Objects (ADO) provider for DSs facilitates this return. The ADO provider for DSs lets you search AD and returns the results in a recordset that you can process as WML. This ADO provider demands a strange and rigid syntax, and the details are certainly beyond the scope of an article about WAP. However, you need to change some specifics to make the code work with your AD. Here are the key areas.
First, assign values to some variables that are specific to your Windows 2000 and AD implementation:
strDn = "CN=Administrator, _
CN=Users,DC= _
InterKnowlogy,DC=com"
strPassword = "password"
strWhere = _
"(physicalDeliveryOfficeName=*)"
StrDn represents the fully qualified distinguished name (DN) of the user who you'll securely bind to AD with. StrPassword is the password of that user. You need to change these values to be specific to your implementation. You can secure AD down to the lowest levels; although a user is authenticated, that user might not have the rights to list employee email and phone data in some implementations. By securely binding to the DS as the Administrator, the page runs under a security context that has permissions to list names, email addresses, and phone numbers. StrWhere represents the beginnings of the Where clause that we use to specify the scope of the search. The "(physicalDeliveryOfficeName=*)" criterion, which essentially means "give me everyone who has the Office attribute persisted," prevents the search from returning synthetic users such as IUSR_MachineName, Administrator, and Guest in the resulting recordset. You can change this attribute to one that is more applicable to your installation or simply leave it blank if you want the search to return all users in the recordset.
Prev. page
1
[2]
3
next page 
