Lesson 8: Responding to browser events and user actions
The do element
The 'do' element is used to specify responses to certain types of user action. It has one required attribute 'type', which holds the kind of user action. The specified response to this action (which we cover in later chapters) is placed between the opening and closing tags of the do element.
A do element can be given an optional 'name' attribute. In lesson 12 we cover a situation in which this attribute proves useful. However, a reader has pointed out another reason why you might want to get in the habit of providing names for your do elements.
The WML 1.0 specification says the following about the name attribute of the do element: "It is an error to specify two or more DO elements with the same NAME in a single card or in the TEMPLATE element. A NAME with an empty value is equivalent to an unspecified NAME attribute. An unspecified NAME defaults to the value of the TYPE attribute."
What follows from this passage is that you can't specify two do elements of the same type in a card without giving these elements different names. For in this case the names of the elements would default to the same string (the string specifying their type), and two do elements with the same name in a card constitutes an error. It is important that such errors be avoided, as gateways may be unable to compile pages with errors. To avoid this kind of problem, therefore, it is probably a good idea to provide names for do elements generally.
The basic markup of the do element can thus be taken as the following:
<do name="unique_name" type="some_type">
some_action
</do>
The extra, optional attributes of the do element are:
|
label
|
- a text string for labeling purposes
|
|
optional
|
- either "true" or "false" ; by setting this to true, the microbrowser is told that it can safely ignore the element
|
The type attribute takes one of the following values. Note that it is up to the browser to decide what kinds of user actions on a particular handset correspond to these generic types of action:
|
accept
|
- something has been accepted or agreed - on a mobile phone this usually corresponds to a press of the left softkey, which may be labeled 'OK' or 'Yes'.
|
|
prev
|
- the 'back' button has been pressed, to make the microbrowser go back one step in its navigation. On a mobile phone this is usually the right softkey.
|
|
help
|
- a request for some sort of help
|
|
options
|
- a context sensitive request for other options
|
|
delete
|
- the deletion of an item
|
|
reset
|
- the pushing of the device's reset button
|
|
unknown
|
- open to be mapped by the browser to any key
|
|
vnd* (where * is any sequence of letters)
|
- reserved for vendor specific tasks
|
The onevent element
The 'onevent' element is used to specify certain kinds of responses to browser events (this is related to, but different from the actions that might cause these events). Like the do element the onevent element has one required attribute - 'type' - but it takes no other attributes. Again, the response to the event is specified by code inside its opening and closing tags; the form of the onevent element is thus:
<onevent type="some_type">
some_action
</onevent>
The type attribute takes one of the following values:
|
onenterforward
|
- this occurs when the card is entered in a 'forward' direction, i.e. when following a link from a card or typing the URL. This is covered in lesson 9
|
|
onenterbackward
|
- this occurs when the card is entered in a 'backwards' direction, i.e. when navigating back to previously seen cards. This is covered in lesson 9
|
|
ontimer
|
- an event triggered after a number of tenths of a second specified by the user. This is covered in lesson 13
|
|
