Deck Declarations
In addition to cards, WML decks can contain optional header and template elements. These elements contain information of relevance to the deck as a whole.
Templates and Precedence of Event Handlers
Templates are used to define event handlers that apply to every card in a deck. This provides a simple way to implement consistent navigation, such as a Home button on every card. A handler specified in a template can be overridden by a similar handler defined in a card. You can create both do-go and on-event handlers for handling both intrinsic and explicit events. As with cards, templates allow attribute short cuts for intrinsic events (such as onenterforward="someURL").
The most common use of templates is for default navigation. The example deck in Figure 3 illustrates the use of templates with an explicit Premises Home navigation handler on every card except the first. On the first card, the default handler is overridden by a card-specific handler that specifies a noop task. Although this handler performs no real action, it has the effect of blocking the template-defined handler so that a user agent will not display the handler on the first card.
){kind=link}
<wml>
<template>
<do type="accept" label="Premises Home" name="home">
<go href="#PremisesHome"/>
</do>
</template>
<card id="PremisesHome">
<do type="accept" name="home">
<noop/>
</do>
<p>
<strong>Select Area</strong><br/>
<a href="kitchen.wml">Kitchen</a>
<a href="#bar">Bar</a>
<a href="#dining">Dining Room</a>
</p>
</card>
<card id="bar">
<p><strong>Bar Inspection</strong> . . . </p>
</card>
<card id="dining">
<p><strong>Dining Room Inspection</strong> . . . </p>
</card>
</wml>
Figure 3 Template event handling with noop
The template in Figure 3 specifies an event handler named home that returns control to the PremisesHome card. Because it doesn't make sense to offer this option on the home card, a noop event handler with the same name is defined on the home card, thus overriding the template handler.
Access Control
WML allows control over the URLs that may request a deck. This control is provided by the access element. The access element is specified inside the optional head element, which, if used, must be the first element in a deck following the <wml> tag. The head element must contain either access elements, meta elements, or a combination of the two. A simple form of access control is provided by the access element's two attributes: domain and path. The domain attribute determines the URLs allowed to request a deck, while the path attribute is used to limit access to resources that are found under a specified directory within the selected domain. Either or both of attributes may be used to limit access. The access element does not contain any other elements. Note that this type of access control relies on the WAP gateway for enforcement and does not replace server-side access control mechanisms.
Figure 4 illustrates deck access control. Only decks originating below the specified path may request this deck. The browser window displays the message shown when a request is made from a card without access rights.
){kind=link}
<wml>
<head>
<access path="/bennett/drafts/figures/appendix"/>
</head>
. . .
</wml>
Figure 4 Deck access control
Meta Tags
The meta element provides a way to express information about a deck. Using named properties, a server may define deck metadata that can be passed as response headers (either WSP or HTTP) to the user agent. However, not all wireless devices may support meta tags because the WML specification does not define or require meta tags, nor does it explain how a user agent should use them.
If you do want to use meta tags, the http-equiv attribute should be used to name the metadata property. Then supply the property value using the content attribute, as in this example:
<wml>
<head>
<meta http-equiv="Cache-Control" content="max-age=0"
forua="true"/>
</head>
...
</wml>
This code uses the Cache-control HTTP directive to ensure that a WML browser supporting this directive will always reload this deck from the server rather than from its cache. The forua attribute specifies that this metadata should be available to the user agent.