Using Basic Navigation
Just like pages on a Web site, cards in a WAP application require navigation capabilities to get from card to card. Because WAP devices currently have no pointing mechanism (such as a mouse or touch screen), all navigation is performed using keypad keys.
Two forms of navigation are supported:
Anchors can be placed around text or images to make them selectable (similar to the HTML <a> tag).
All WAP devices have action keys (usually at least two of them) which can be programmed as needed.
We'll now briefly look at each of these.
▸ Navigation is covered extensively in Chapter 4, "Card Navigation."
Creating Links
WML links are very similar to their HTML counterparts. The text (or image) to be linked is enclosed within <a> and </a> tags, and the browser uses some indicator (usually underlining) to indicate that it can be selected. The actual selection mechanism varies from one device to the next, although most devices allow the Accept button to be used for selection.
To demonstrate the use of links, Listing 3.6 contains an updated version of our deck of cards.
Listing 3.6 Using Links with a Simple Deck
The original cards in this deck have not changed at all. The only change is the inclusion of the following new card (which is now the first card in the deck):
<card id="index">
<p>
<a href="#card1">Card 1</a>
<br />
<a href="#card2">Card 2</a>
<br />
<a href="#card3">Card 3</a>
<br />
</p>
</card>
This card lists the names of three cards, one per line (separated by a line break). Each card name is a link created with <a> and </a> tags. The URL to link to is specified in the href attribute, and in this example the link is to cards within the same deck (using the syntax explained earlier in this chapter).
The code in Listing 3.6 create a screen like the one shown in Figure 3.9.
Figure 3.9. Links can be used to make blocks of text or images selectable.
Now any card can be displayed by selecting it from the list and pressing the device's Accept button.
Using Actions
Actions are unique to WML and have no real HTML counterpart. Every WAP-enabled device has task buttons, usually at least two, and usually directly beneath the display. On most devices the left button is the accept button, and the right is the back button, but this is not always the case. Regardless of the number of buttons and their position, one thing is certain: These buttons do exist, and you can control what they do.
Programming an action requires associating a URL with a button type, and this is done using the <do> tag. To demonstrate this, let's look at a simple example:
<do type="accept"> <go href="/index.wml" /> </do>
<do> requires that a button type be specified; here we used the accept button. Between the <do> and </do> tags comes the action to be performed, here we used a <go> tag to specify a URL to go to. (There are other important details in using actions, as will be explained in Chapter 4).
For now we'll update the deck example to provide a back button on each detail card page so that you can easily get back to the first card (as seen in Figure 3.1). Listing 3.7 contains the updated code.
Figure 3.10. All device action buttons can be programmed and labeled as needed.
Listing 3.7 Creating an Action Button
In this listing, each of the three detail cards has been updated to include the following code:
<do type="options" label="Back"> <prev /> </do>
This code programs the options button (usually the right button) and also provides a label that will be displayed above it (as seen in Figure 3.10). The action associated with this button is <prev />, a WML tag that acts as a previous button and returns to the previous card. Using this button it is now possible to go back to the card list from within each card.
Using Templates
One thing you'll notice in Listing 3.7 is that the action code was repeated for each and every detail card in the deck. This is highly inefficient:
Having to reenter the same code over and over is highly error prone because there is the likelihood that one card will be missed or mistyped.
Having the code in multiple places makes making updates more complex because there is always the risk that one or more occurrences will be overlooked.
All that extra code increases the page size—not an efficient use of precious bandwidth.
To solve this problem, WML supports the use of template code, blocks of code specified at the deck level which apply to all cards in a deck. Listing 3.8 contains an updated deck of cards; this time the back button code is not specified in each card, but in a <template> block at the top of the deck. Any code in between <template> and </template> will apply to all cards in the deck as if it had been typed there directly.
Listing 3.8 Using Templates
There's only one problem with this code, and to see what I mean, look at Figure 3.11. As you can see, every card now has a back button, even the first card (the list of card names) which should not have one. When using <template> code, every card in the deck is affected, and sometimes too many cards.
Figure 3.11. Template code is applied to every card in a deck.
The solution here is to provide a card level override where needed. If the same action is provided at both the deck and card level, the card code always takes precedence. This means that we can use the <template> code to program the back button and then tell the browser to not use that code for the first card. Listing 3.9 contains the updated code:
Listing 3.9 Using Templates and Shadowing
The only difference here is the inclusion of the following code in the first card:
<do type="options"> <noop /> </do>
This <do> tag overrides <template> <do> tag and specifies no label. The action associated with this button is now <noop />—or "no operation". This strange tag tells the browser to do nothing at all and is used for shadowing—turning off deck-level options for specific cards.
Note
Only actions of the same type of overridden. If you specified an options button at the deck level and an accept button at the card level, both buttons would be displayed—the card level button would not override the deck level button as the types are different.
So now you have a complete working (albeit somewhat boring) deck of cards. The first deck lists the individual cards which can be selected for display, and each card but the top level card has a back button that is programmed using common-code.