Wireless Markup Language--Beyond the Basics
- Wireless Markup Language--Beyond the Basics
- Events, Tasks, and History
- Timers
- Tasks
- Deck Declarations
- Named Character Entities
- Scripting
In the third article in the Wireless Access Protocol series, authors Chris Bennett and Frank Coyle explore the features of WML in more detail.
In our last article, we looked at the basics of the Wireless Markup Language (WML), including decks and cards, layout, input, and navigation. Now we'll continue our exploration of WML and extend our hypothetical health inspection system example to illustrate some additional WML features, including the following:
-
Variables, parameters, and context
-
Events, tasks, and history
-
Deck declarations
-
Grouping
-
Scripting
-
Named character entities
Our discussion is based on WML version 1.3 although most of what we talk about applies to earlier versions. Note that most browsers currently support WML 1.1, with a few supporting version 1.2. Many differences also exist between browser interpretations of the WML specifications, and the examples in this chapter may look quite different when displayed on a user agent other than the Phone.com simulator used for our screen shots.
Variables, Parameters, and Context
Variables, parameters, and context are the ingredients for maintaining state within WML. Variables hold data values within the client and are maintained by the WML browser context. Parameters export this client state to the server. Navigation history, which we discuss separately, is also maintained in the browser context.
Variables
Variables allow us to pass information from card to card, both in and between decks. Variables are automatically defined and set when a value is entered in an input field or an item is selected from a select list. For example, <input name="light"/> will create and populate the light variable with the user-supplied text. Variables can also be set explicitly by the setvar method inside task elements such as go, prev, or refresh. In WML, the contents of variables are treated as strings.
To define a variable, simply use its name. To access a variable, use the dollar sign reserved character—for example, $var or $(var). Brackets are required when the variable is not clearly separated from surrounding markup. For example, if the variable prefix has a value of Mac, the WML string $(prefix)Donald would yield the resultant MacDonald after variable substitution.
Variables must begin with a letter or underscore (_) and may contain underscores, letters, and numbers. In WML, variables may be referenced anywhere character data is legal (between tags) and also within certain attributes (such as href). Variables cannot be referenced within attributes such as length or name, when the attribute values must be fixed before processing.
The following example illustrates setting the variable progress inside a go task element to provide information about how we arrived at the Step2 card. In the WML for the Step2 card, we refer to the contents of the variable by prefixing the variable name with $, as in $progress.
<go href="#Step2"> <setvar name="progress" value="Step 1 completed"/> </go> . . <card id="Step2"> <p>Progress: $progress</p> . . </card>
This style of coding might be used when a user can arrive at the Step2 card from several different paths. Here the Step2 card displays progress as a reminder to the user how he or she arrived. Note that the setvar element is an empty element and, other than requiring the common attributes (see the accompanying sidebar), requires that you specify a name and a value.
Common WML Attributes
Because attributes are useful when describing elements, it should come as no surprise that some attributes appear with most WML elements. The id attribute is used to give a unique identifier to any element, allowing reference to the element from another element. The class attribute can be used to associate an element with a class or classes to which the element belongs. The xml:lang attribute allows you to specify a natural or formal language in which text has been written. Although it is not found with all elements, the title attribute is commonly used to provide a short name that can be used when a WML browser displays the element.
Variables live locally in the WML client, accessible from both WML cards and WMLScript programs (which we'll cover in the next article). To make client data available to the server programs, we need to understand parameters.
Parameters
Parameters pass information between the mobile device and a server during a URL request. The postfield element is used to define and set parameters, and it may be used inside go tasks:
<go href="myScript.cgi"> <postfield name="progress" value="Step 1 completed"/> </go>
This code results in a GET request (the default HTTP method in WML) that triggers myScript.cgi on the server. As in an HTTP GET, the progress parameter is appended to the URL and passed to the server. If post had been used as the method attribute, an HTTP POST request would invoke the name URL, passing the postfield parameter separately. Like setvar, the postfield element is an empty element whose name and value are set using the attributes name and value. Note that values can also be passed to a server using links (the anchor, or a, element) and are set as part of the href URL attribute (<a href="myScript.cgi?progress=$progress">). The & named character entity (described toward the end of this article) must be used to separate multiple variables.
Context
WML uses a single browser (client-side) context to save all state. This includes the navigation history (a linked set of URLs that records the user's recently visited cards) and all variables that have been set within this history. The context can be reset using the newcontext card attribute (<card newcontext = "true">). Do not confuse this context with the server context or with the deck cache that a browser maintains to improve retrieval efficiency.