Webmaster''''s Guide to the Wireless Internet part 39 pps
Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (90.85 KB, 10 trang )
352 Chapter 8 • Wireless Enabling Your Big Bandwidth Site
map { print "$_ : $ENV{$_}<br>" } keys %ENV;
print "</DISPLAY></HDML>";
} elsif (&detect_accept eq "wml") {
#print WML header and print out results
print "Content-type:text/vnd.wap.wml\n\n";
print<<HEAD;
<?xml version="1.0"?>
<!DOCTYPE wml PUBLIC
"-//WAPFORUM//DTD WML 1.1//EN"
" />HEAD
print "<wml><card id='first' title='printenv'><p>";
map { print "$_ : $ENV{$_}<br/>" } keys %ENV;
print "</p></card></wml>";
}
To install the program, save the above text as printenv.cgi, and put it in your
cgi-bin. If you are using a UNIX system, you will need to make sure that the file
is executable and that the first line of the file corresponds to the location of your
Perl installation.
You can request the file ( with
most any browser and view the complete list of environmental variables.There is
no flow control in this script, so bear in mind that when you send the content to
an actual device you may find that the deck is too large for the device to handle.
However, the emulators that are available for both the UP.Browser and the Nokia
WAP Toolkit do not suffer from the limitations imposed by WAP gateways.They
will deliver the deck contents even if they are too large for an actual device.
Redirecting Your Users to Static Content
Now that your Web server is up and running and you know where to look to
find out what types of content your users can accept, you can use this knowledge
to give your users what they want: content. In this section we will cover how to
redirect your users to separate static pages based on their browser. If you imple-
ment this on your site, it will allow you to send all of your users to the same
URL (), regardless of the device that they are using.When
www.syngress.com
159_wg_wi_08 10/22/01 5:21 PM Page 352
Wireless Enabling Your Big Bandwidth Site • Chapter 8 353
the user queries your URL, they will execute the redirection script (index.cgi)
and be directed to an appropriate index page coded in either HTML,WML, or
HDML.
We will provide examples in PHP and Perl in the following sections, and also
provide code samples of pages to make sure that the redirection example is
working correctly.The first code sample should look very familiar. It’s a small
HTML page that informs you (the user) that your script is correctly installed.The
last two code samples are written in WML and HDML, respectively, and will dis-
play the same message as the first example.
Redirecting Users in PHP
PHP stands for “PHP Hypertext Preprocessor” . It is a server-side scripting lan-
guage that allows you to embed control structures within your markup. It has
recently grown in popularity due largely to its portability, flexibility, and ease
of use.
<?
$accept = getenv("HTTP_ACCEPT");
if ( eregi("vnd\.wap\.wml",$accept) ) {
header("Location:/wml/index.wml");
} elseif ( eregi("text/x-hdml",$accept) ) {
header("Location:/hdml/index.hdml");
} else {
header("Location:/html/index.html");
}
?>
Redirecting Users in Perl
Practical Extraction and Reporting Language (Perl) has long been a favorite lan-
guage of many Webmasters due to its utility and interpretive syntax. Perl can be
used from the UNIX shell or implemented as a Web-accessible CGI program. In
this subsection, we will provide a Perl program that will redirect users to a page,
depending on the browser that they use to request the page.
#!/usr/bin/perl
$accept = $ENV{HTTP_ACCEPT};
if ( $accept =~ m%text/vnd.wap.wml%i ) {
www.syngress.com
159_wg_wi_08 10/22/01 5:21 PM Page 353
354 Chapter 8 • Wireless Enabling Your Big Bandwidth Site
print "Location:index.wml\n\n";
} elsif ( $accept =~ m%text/x-hdml%i ) {
print "Location:index.hdml\n\n";
} else {
print "Location:index.html\n\n";
}
exit;
Code for index.html:
<html>
<head>
<title>Congratulations!</title>
</head>
<body>
<h1>Congratulations!</h1>
<p>If you can see this, it means that the redirect script installed
on this server is working correctly!</p>
<p>Your language type is: HTML</p>
</body>
</html>
The code of this page is fairly straightforward; you probably don’t even need
to put it into a browser to know exactly how it will look (Figure 8.6)!
www.syngress.com
Figure 8.6 Output of index.html
159_wg_wi_08 10/22/01 5:21 PM Page 354
Wireless Enabling Your Big Bandwidth Site • Chapter 8 355
Code for index.wml (also refer to Figure 8.7):
<?xml version="1.0"?>
<!DOCTYPE wml PUBLIC
"-//WAPFORUM//DTD WML 1.1//EN"
" /><wml>
<card id="congrats" title="Congratulations">
<p>
Congratulations!<br/>
Your redirect script is working!
<br/></p>
<p>Your language type is: WML</p>
</card>
</wml>
As noted throughout this book, one very important thing to note about
WML documents is that they must contain valid markup. Unlike in HTML,
there can be no stray or misplaced tags in your document.You’ll find this out
very quickly when you start to code your own WML on a regular basis!
Code for index.hdml (also refer to Figure 8.8):
<hdml version=3.0>
<display>
Congratulations!<br>
Your redirect script is working!<br>
<br>
Your language type is: HDML
www.syngress.com
Figure 8.7 Output for index.wml
159_wg_wi_08 10/22/01 5:21 PM Page 355
356 Chapter 8 • Wireless Enabling Your Big Bandwidth Site
/display>
</hdml>
The third markup language that we will use is Handheld Device Markup
Language (HDML), which is used by many of the legacy phones available in the
United States. It is entirely up to you to decide which languages to support, but
we suggest that if you want to reliably deliver content to users in the United
States, build at least minimal HDML support into your site.
The first element of this document specifies that it is an HDML document
and that it is written in HDML 3.0. All HDML documents require a version
statement in the first line.The next element, <display>, is a type of card that can
be rendered with HDML.The other two types of cards that can be used are
<nodisplay>, which does not display anything to the user, and <choice> cards,
which allow the user to pick from a list of options.The HDML that you deliver
does not need to be validated against a DTD (like WML), but it is always recom-
mended that you code cleanly.
Support for HDML is waning as support for WML grows, but there are a
great many phones still in use that are only capable of rendering HDML. Some
WAP gateways do on-the-fly transcoding of HDML to WML and vice-versa, for
phones that do not natively support either language. Some gateways will even
code HTML to WML, which we will touch on in the next section.
Optimizing Content Distribution
Just as you take care to manage the file system of your existing Web site, you
should put some thought into the organization of your wireless site.You may
wish to maintain two Web sites running on the same machine, one with the
name of www.yoursite.com, and one with the name of wap.yoursite.com.This
offers some benefits, as long as your users know where they are supposed to go.
www.syngress.com
Figure 8.8 Output for index.hdml
159_wg_wi_08 10/22/01 5:21 PM Page 356
Wireless Enabling Your Big Bandwidth Site • Chapter 8 357
On the other hand, you could install the redirection script covered above to send
your users to the correct location, wherever that may be.
Regardless of the technical issues of how you manage your content, it
makes sense to take a critical look at your current Web site, and to consider what
you want to provide to your wireless users on your wireless Web site. In this sec-
tion, we will ask the important questions that surround building a wireless Web
site, and discuss the issues surrounding the conversion of existing sites to the
wireless Internet.
Choosing Mobile Content
One of the first steps of building any site is choosing what content to display on
the site.This concept is of particular importance when we consider taking our
existing Web site to the wireless Internet.The primary questions that arise in
adapting a large existing site to the wireless Internet are the following:
1. What content/services might our users want to access while they are
mobile?
2. What limitations are there to the existing mobile interfaces that we must
consider?
Most likely, you will not be able (or will not want) to deliver all of your
existing site to mobile users. Critically examine your content and applications to
ensure that they are useful to the mobile user. For example, if you run a portal
site, you may want to deliver wireless news, weather, and email to your mobile
users, as this information is of most value to them. Content such as book reviews,
in-depth coverage of intricate issues, and user message boards or forums are best
left to the desktop browsers.
Remember that mobile users often have a very small window on your site as
well as a small-bandwidth connection, and that they will not benefit as greatly
from the high-bandwidth components of your site (such as images) or have the
ability to scroll through pages and pages of links.Try not to overwhelm the user.
Provide a small list of useful actions they can perform on your site, and the wire-
less portion of your site will be more successful.
Convert or Redevelop?
There are several approaches to adapting existing Web content to the wireless
Internet, and the optimal approach depends largely on the nature of the existing
www.syngress.com
159_wg_wi_08 10/22/01 5:21 PM Page 357
358 Chapter 8 • Wireless Enabling Your Big Bandwidth Site
content.There are roughly three options for enabling your site for wireless
consumption:
1. You could run a program that automatically traverses the HTML docu-
ment area of your site and produces HTML that is valid.You could then
use Extensible Style Language Transformations (XSLT) to transform the
valid HTML into a WML version according to an XSL ruleset.
2. Alternately, you might write a ‘wrapper’ program that will take a request
from a wireless browser and act as a proxy to the Internet.This program,
upon receiving a request, would retrieve and format the resulting con-
tent for a handheld device.
3. You could rebuild a new wireless version of your site, taking into con-
sideration the needs of wireless users and the nature of your content.
So how do you decide what to do? The first option is useful if you need to
get your site on the wireless Internet as soon as possible, and if your site is made
up primarily of text-based content with minimal formatting.The downside of
this option is that you cannot assure that your XSL, which operates on a static
rule set, will generate a user-friendly version of your site. If your site is already
coded in XML, then you can eliminate the first step of this solution and go
straight to XSLT.
The second solution is a good idea if you are familiar with the existing con-
tent and can reliably translate it on-the-fly. It certainly helps if the content is gen-
erated by a machine rather than by a human being, and is best suited for
low-bandwidth applications, such as entertainment calendars, traffic and weather
information, and movie listings.Another upside is that you can extract only the
elements that your users need, something that they will certainly appreciate.The
downside of this solution is that the actual request will be much slower to the
user because they are not only waiting for your server to return content, but they
are also waiting for your server to retrieve, convert, and deliver content.
Depending on the amount of formatting you must do, and the speed of the
HTML-based application, this delay may render your application too slow for the
mobile user.
We favor the third option because it is most likely to generate a user-friendly
wireless site. Many of the existing complaints about the wireless Internet could
have been avoided if the early adopters took this strategy rather than the first two
options.The problems associated with this option primarily have to do with
development time and resources because it is not always economically feasible to
www.syngress.com
159_wg_wi_08 10/22/01 5:21 PM Page 358
Wireless Enabling Your Big Bandwidth Site • Chapter 8 359
start from scratch. Nonetheless, it makes the most sense for you to consider the
needs and desires of your users, and build your site around those needs.
NOTE
Google (www.google.com) has developed an intelligent on-the-fly con-
verter that will allow WML browsers to view HTML sites. It works for
small, basic, text-based sites, but ultimately fails on sites that contain
large amounts of graphic-based navigation elements or form-based con-
tent. Using this converter should be enough to convince you that any
automated conversion system, no matter how intelligent, fails when
compared to a wireless site designed with human usability in mind.
It is certainly possible to convert HTML (even bad HTML) to WML, but is
it desirable to do so? Most notably, existing translation mechanisms do not readily
allow for the file-size limitations of mobile devices. Furthermore, not all elements
of HTML are supported in WML, and any user interface will certainly be sub-
optimal unless re-engineered and re-coded by a human being. It is our recom-
mendation that you consider your application from the user’s perspective.Ask
yourself: would I want to have my content available on a handheld device? Does
it provide some utility to my users? Do the benefits outweigh the costs of devel-
opment? If the answer to any or all of those questions is no, then you should skip
to the next chapter!
Delivering Wireless Data
Making data available to mobile users is a key advantage that building a wireless
Web site can provide. If we are providing information from a database to users on
the WWW, we can make this same data available to users on wireless devices.
If your Web site is database-driven and content is separated from presentation,
you should be able to generate an effective wireless Web site fairly painlessly.You
will certainly have an easier time building a site from a database of content than
by building one from many static pages of HTML that have been hacked
together over a long period of time by multiple people with varying skill-levels
and coding styles.
In this section, we will cover the coding of a module that will allow you to
adapt your existing data application to the wireless Internet.The theories and
www.syngress.com
159_wg_wi_08 10/22/01 5:21 PM Page 359
360 Chapter 8 • Wireless Enabling Your Big Bandwidth Site
issues covered here will make sense for any existing Web site that separates con-
tent from presentation.
Making Your Applications Accessible
The first step to delivering wireless data is determining what type of device is
requesting the content.We have covered the means of detecting devices and redi-
recting users previously in this chapter, but now we will apply this detection
scheme as a means of selecting an interface to your application.
We will cover the basics of building a library that can be accessed from many
applications, and return a result that contains the language to be used, and the
type of device in order to apply some logic to the presentation of the retrieved
data.The routines, regardless of the programming language used, look something
like this pseudocode example:
IF device_supports_wml AND device_does_not_support_hdml
$language = "wml"
ELSE IF device_supports_hdml
$language = "hdml"
ELSE IF device_supports_html
$language = "html"
ELSE
$language = "unknown"
IF device_is_phone
$devicetype = "phone"
ELSE IF device_is_PDA
$devicetype = "PDA"
ELSE IF device_is_Web_browser
$devicetype = "Web_browser"
ELSE
$devicetype = "unknown"
Once we have authored this routine and provided a means for it to be called
from our applications, we can use it to determine how and in what quantities to
display our content. For example, if the request for data came from a mobile tele-
phone, we can assume that our final deck of results should not contain more than
1397 bytes of data. If the same request came from a PDA, we might enable more
www.syngress.com
159_wg_wi_08 10/22/01 5:21 PM Page 360
Wireless Enabling Your Big Bandwidth Site • Chapter 8 361
chunks of the data to be displayed on a given card in the deck (but still minimize
the size of the deck because PDA users pay ‘per-byte’.) If the request came from
a Web browser, we might be able to send back all of the results in one page, with
extensive formatting.
The example in Figure 8.9 is provided in Perl, but you should be able to
adapt it to the server-side scripting language of your choice.
Figure 8.9
Language and Device Detection in Perl
#!/usr/bin/perl
use strict;
my $device = &detect_device;
my $language = &detect_language;
#detects language according to HTTP_ACCEPT
sub detect_language {
my $lang;
my $accept = $ENV{HTTP_ACCEPT};
if ( $accept =~ m%text/vnd\.wap\.wml% ) {
$lang = "wml";
} elsif ( $accept =~ m%text/x-hdml% ) {
$lang = "hdml";
} elsif ( $accept =~ m%text/x-html% ) {
$lang = "html";
} else {
$lang = "";
}
return $lang;
}
#detects device against known UA list (from device.cgi)
sub detect_device {
my $type;
my $uagent = $ENV{HTTP_USER_AGENT};
open(DB,'<ualist.txt');
while(<DB>) {
www.syngress.com
Continued
159_wg_wi_08 10/22/01 5:21 PM Page 361
